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PREFACE 


Vulnerability  assessment  methodologies  for  information  systems  have  been  weakest 
in  their  ability  to  guide  the  evaluator  through  a  determination  of  the  critical  vulner¬ 
abilities  and  to  identify  appropriate  security  mitigation  techniques  to  consider  for 
these  vulnerabilities.  The  Vulnerability  Assessment  and  Mitigation  (VAM)  methodol¬ 
ogy  attempts  to  fill  this  gap,  building  on  and  expanding  the  earlier  RAND  methodol¬ 
ogy  used  to  secure  a  system’s  minimum  essential  information  infrastructure  (MEII). 
The  VAM  methodology  uses  a  relatively  comprehensive  taxonomy  of  top-down 
attributes  that  lead  to  vulnerabilities,  and  it  maps  these  vulnerability  attributes  to  a 
relatively  comprehensive  list  of  mitigation  approaches.  The  breadth  of  mitigation 
techniques  includes  not  only  the  common  and  direct  approaches  normally  thought 
of  (which  may  not  be  under  one’s  purview)  but  also  the  range  of  indirect  approaches 
that  can  reduce  risk.  This  approach  helps  the  evaluator  to  think  beyond  known  vul¬ 
nerabilities  and  develop  a  list  of  current  and  potential  concerns  to  head  off  surprise 
attacks. 

This  report  should  be  of  interest  to  individuals  or  teams  (either  independent  of  or 
within  the  organization  under  study)  involved  in  assessing  and  mitigating  the  risks 
and  vulnerabilities  of  information  systems  critical  to  an  organization’s  functions — 
including  the  discovery  of  vulnerabilities  that  have  not  yet  been  exploited  or  encoun¬ 
tered.  The  report  may  also  be  of  interest  to  persons  involved  in  other  aspects  of 
information  operations,  including  exploitation  and  attack. 

This  report  refers  to,  in  multiple  places,  a  prototype  spreadsheet  that  implements  the 
methodology  using  Microsoft  Excel  2000.  Readers  may  obtain  a  copy  of  this  spread¬ 
sheet  online  atwww.rand.org/publications/MR/MR1601/. 

Unpublished  RAND  research  by  the  authors  of  this  report  explored  the  issues  in 
applying  VAM  methodology  to  military  tactical  information  systems.  This  research 
may  be  available  to  authorized  government  individuals  by  contacting  Philip  Anton 
(anton@rand.org)  or  Robert  Anderson  (anderson@rand.org). 

This  study  was  sponsored  by  the  Information  Technology  Office  (ITO)  of  the  Defense 
Advanced  Research  Projects  Agency  (DARPA).  It  was  conducted  in  the  Acquisition 
and  Technology  Policy  Center  of  RAND’s  National  Defense  Research  Institute,  a  fed¬ 
erally  funded  research  and  development  center  (FFRDC)  sponsored  by  the  Office  of 
the  Secretary  of  Defense,  the  Joint  Staff,  the  unified  commands,  and  the  defense 
agencies. 
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SUMMARY 


As  information  systems  become  increasingly  important  to  the  functions  of  organiza¬ 
tions,  security  and  reliable  operation  of  these  systems  are  also  becoming  increasingly 
important.  Interoperability,  information  sharing,  collaboration,  design  imperfec¬ 
tions,  limitations,  and  the  like  lead  to  vulnerabilities  that  can  endanger  information 
system  security  and  operation.  Unfortunately,  understanding  an  organization’s 
reliance  on  information  systems,  the  vulnerabilities  of  these  systems,  and  how  to 
mitigate  the  vulnerabilities  has  been  a  daunting  challenge,  especially  for  less  well- 
known  or  even  unknown  vulnerabilities  that  do  not  have  a  history  of  being  exploited. 

RAND  has  developed  and  evolved  a  methodology  to  help  an  analyst  understand 
these  relationships,  facilitate  the  identification  or  discovery  of  system  vulnerabilities, 
and  suggest  relevant  mitigation  techniques.  This  Vulnerability  Assessment  and  Miti¬ 
gation  (VAM)  methodology  builds  on  earlier  work  by  Anderson  et  al.  (1999)  and  fills  a 
much-needed  gap  in  existing  approaches  by  guiding  a  comprehensive  review  of  vul¬ 
nerabilities  across  all  aspects  of  information  systems  (including  not  only  cyber 
objects  but  also  physical,  human/social,  and  infrastructure  objects1)  and  mapping 
the  vulnerabilities  to  specific  security  techniques  that  can  address  them. 

The  VAM  methodology  takes  a  top-down  approach  and  seeks  to  uncover  not  only 
vulnerabilities  that  are  known  and  exploited  or  revealed  today  but  also  the  vulner¬ 
abilities  that  exist  yet  have  not  been  exploited  or  encountered  during  operation. 
Thus,  the  methodology  helps  to  protect  against  future  threats  or  system  failures 
while  mitigating  current  and  past  threats  and  weaknesses.  Also,  sophisticated  adver¬ 
saries  are  always  searching  for  new  ways  to  attack  unprotected  resources  (the  “soft 
underbelly”  of  the  information  systems).  Thus,  the  methodology  can  be  valuable  as  a 
way  to  hedge  and  balance  both  current  and  future  threats.  Also,  the  complexity  of 
information  systems,  and  their  increasing  integration  with  organizational  functions, 
requires  additional  considerations  to  ensure  that  design  or  architectural  weaknesses 
are  mitigated. 


1An  “object”  is  any  part  of  the  system  that  contributes  to  the  function,  execution,  or  management  of  the 
system.  The  partitioning  of  information  system  components  into  conceptual  “objects”  facilitates  the 
consideration  of  components  that  can  otherwise  be  neglected  in  security  assessments  (i.e.,  security 
breaches  can  arise  from  weaknesses  in  physical  security,  human  limits  and  behavior,  social  engineering, 
or  compromised  infrastructure  in  addition  to  the  more  publicized  compromises,  such  as  network  attacks). 
It  also  allows  the  separation  of  vulnerability  attributes  from  the  system  component  that  may  have  that 
attribute. 
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MAPPING  SECURITY  NEEDS  TO  CRITICAL  ORGANIZATIONAL 
FUNCTIONS 

The  methodology  employs  the  following  six  steps: 

1.  Identify  your  organization’s  essential  information  functions. 

2.  Identify  essential  information  systems  that  implement  these  functions. 

3.  Identify  vulnerabilities  of  these  systems. 

4.  Identify  pertinent  security  techniques  to  mitigate  these  vulnerabilities. 

5.  Select  and  apply  techniques  based  on  constraints,  costs,  and  benefits. 

6.  Test  for  robustness  and  actual  feasibilities  under  threat. 

Repeat  steps  3-6  as  needed. 

The  methodology’s  guiding  principles  are  the  links  back  through  critical  systems  to 
important  organizational  functions  as  well  as  assessments  of  the  appropriateness  of 
security  techniques  in  each  specific  situation.  This  approach  not  only  guides  the 
evaluator  through  the  myriad  possible  security  techniques  selections  but  also  pro¬ 
vides  management  rigor,  prioritization,  and  justification  for  the  resources  needed, 
helping  others  to  understand  what  needs  to  be  done  and  why. 

IDENTIFYING  WELL-KNOWN  AND  NEW  VULNERABILITIES 

Vulnerabilities  arise  from  the  fundamental  properties  of  objects.  The  VAM  method¬ 
ology  exploits  this  fact  to  provide  a  relatively  comprehensive  taxonomy  of  properties 
across  all  object  types,  leading  the  evaluator  through  the  taxonomy  by  using  a  table 
of  properties  applied  to  physical,  cyber,  human/social,  and  infrastructure  objects  (see 
Table  S.l).  This  approach  helps  the  evaluator  avoid  merely  listing  the  standard,  well- 
known  vulnerabilities  (a  bottom-up,  historical  approach),  but  asks  questions  outside 
the  range  of  vulnerabilities  commonly  identified.  For  example,  vulnerabilities  arise 
not  only  from  such  access  points  as  holes  in  firewalls  but  also  from  such  behavioral 
attributes  as  gullibilities  or  rigidities.  These  attributes  may  be  exhibited  by  all  types  of 
system  components:  cyber,  physical,  human/social,  or  infrastructure. 

IDENTIFYING  AND  DOWNSELECTING  MITIGATIONS  TO  IMPLEMENT 

The  VAM  methodology  identifies  a  relatively  comprehensive  taxonomy  of  security 
technique  categories  to  prevent,  detect,  and  mitigate  compromises  and  weaknesses 
in  information  systems  (see  Figure  S.l).  These  techniques  are  grouped  by  techniques 
that  improve  system  resilience  and  robustness;  techniques  that  improve  intelligence, 
surveillance,  and  reconnaissance  (ISR)  and  self-awareness;  techniques  for  counterin¬ 
telligence  and  denial  of  ISR  and  target  acquisition;  and  techniques  for  deterrence  and 
punishment. 
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Table  S.l 

The  Vulnerability  Matrix 
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Object  of  Vulnerability 


Physical  Cyber  Human/Social  Enabling  Infrastructure 


Attributes 

Hardware  (data  storage, 
input/output,  clients, 
servers),  network  and 
communications,  locality 

Software,  data, 
information,  knowledge 

Staff,  command, 
management,  policies, 
procedures,  training, 
authentication 

Ship,  building,  power, 
water,  air,  environment 

Singularity 

Uniqueness 

Centrality 

o 

0) 

Homogeneity 

o 

< 

c 

CD 

Separability 

CO 

CD 

□ 

Logic/ 

implementation 
errors;  fallibility 

Design  sensitivity/ 

fragility/limits/ 

finiteness 

Un  recoverability 

Behavioral  sensitivity 
fragility 

Malevolence 

Rigidity 

JZ 

CD 

CQ 

Malleability 

Gullibility/ 

deceivability/naivete 

Complacency 

Corruptibility/ 

controllability 

Accessible/ 

detectable/ 

identifiable/ 

transparent/ 

interceptable 

General 

Hard  to  manage  or 
control 

Self  unawareness 
and  unpredictability 

Predictability 
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The  methodology  uses  multiple  approaches  to  identify  which  security  techniques 
should  be  considered  to  address  the  identified  vulnerabilities. 

First,  a  matrix  maps  each  vulnerability  to  security  techniques  that  are  either  primary 
or  secondary  candidates  for  mitigating  the  vulnerability.  The  matrix  also  cautions 
when  security  techniques  can  incur  additional  vulnerabilities  when  they  are  imple¬ 
mented  (see  Figures  S.2  and  S.3).  Finally,  the  matrix  notes  the  cases  in  which  vulner¬ 
abilities  actually  facilitate  security  techniques,  thus  resulting  in  a  beneficial  side 
effect. 

Second,  users  will  come  to  this  methodology  with  different  intents,  responsibilities, 
and  authorities.  The  methodology  reflects  this  fact  by  filtering  candidate  security 
techniques  based  on  the  evaluator’s  primary  job  role — operational,  development,  or 
policy.  The  methodology  also  partitions  information  system  compromises  into  the 
fundamental  components  of  an  attack  or  failure:  knowledge,  access,  target  vulnera¬ 
bility,  non-retribution,  and  assessment.  Knowledge  of  the  target  system  is  needed  to 
design  and  implement  the  attack.  Access  is  needed  to  collect  knowledge  and  execute 
an  attack  on  the  target  vulnerability.  Without  the  core  target  vulnerability,  no  attack 
is  possible  in  the  first  place.  Non-retribution  (or  even  its  first  component  of  non¬ 
attribution)  is  needed  to  minimize  backlash  from  the  operation.  Finally,  assessment 
of  an  attack’s  success  is  critical  when  other  operations  rely  on  the  success  of  the 
attack.  In  the  case  of  a  nondeliberate  system  failure,  only  the  target  vulnerability  that 
enables  the  failure  is  the  critical  component. 


Resilience/Robustness 

•  Heterogeneity 

•  Redundancy 

•  Centralization 

•  Decentralization 

•  VV&A;  SW/HW  engineering;  evaluations; 
testing 

•  Control  of  exposure,  access,  and  output 

•  Trust  learning  and  enforcement  systems 

•  Non-repudiation 

•  Hardening 

•  Fault,  uncertainty,  validity,  and  quality 
tolerance  and  graceful  degradation 

•  Static  resource  allocation 

•  Dynamic  resource  allocation 

•  Management 

•  Threat  response  structures  and  plans 

•  Rapid  reconstitution  and  recovery 

•  Adaptability  and  learning 

•  Immunological  defense  systems 

•  Vaccination 
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ISR  and  Self-Awareness 

•  Intelligence  operations 

•  Self-awareness,  monitoring,  and 
assessments 

•  Deception  for  ISR 

•  Attack  detection,  recognition, 
damage  assessment,  and 
forensics  (self  and  foe) 

Counterintelligence,  Denial  of  ISR 

and  Target  Acquisition 

•  General  counterintelligence 

•  Deception  for  Cl 

•  Denial  of  ISR  and  target 
acquisition 

Deterrence  and  Punishment 

•  Deterrence 

•  Preventive  and  retributive 
Information/military  operations 

•  Criminal  and  legal  penalties  and 
guarantees 

•  Law  enforcement;  civil 
proceedings 


Figure  S.l — Security  Mitigation  Techniques 
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Figure  S.2 — The  Concept  of  Mapping  Vulnerabilities  to  Security  Mitigation  Techniques 
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Security  technique  may: 

2:  mitigate  vulnerability  (primary) 

1 :  mitigate  vulnerability  (secondary) 
0:  be  facilitated  by  vulnerability 
-1 :  incur  vulnerability  (secondary) 
-2:  incur  vulnerability  (primary) 


Homogeneity 
Separability 


Logic/ 

Implementation 
Errors;  Fallibility 

Design 

Sensitivity/Fragility/ 

Limits/Finiteness 

-1 

2 

m 


CB 


mil 


Figure  S.3 — Values  Relating  Vulnerabilities  to  Security  Techniques 
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In  addition  to  filtering  the  techniques  further,  this  partitioning  exploits  the  important 
observation  that,  in  attacks,  denial  of  a  critical  component  of  an  attack  can  prevent 
an  attack  without  necessarily  addressing  the  fundamental  target  vulnerability.  The 
partitioning  also  suggests  additional  options  for  evaluators,  based  on  their  situation 
and  job  role.  For  example,  operational  users  cannot  redesign  the  architecture  of  an 
information  system  developed  by  others,  but  they  can  often  limit  knowledge  and 
access  to  the  system. 

AN  AUTOMATED  AID  IN  USING  THE  VAM  METHODOLOGY 

Finally,  an  automated  prototype  tool  implemented  as  an  Excel  spreadsheet  greatly 
improves  the  usability  of  the  methodology.  The  tool  guides  the  evaluator  through 
assessment  of  vulnerabilities,  evaluation  of  risks,  review  of  cautions  and  barriers  to 
security  techniques,  selection  of  techniques  to  implement,  and  estimation  of  the 
risks  after  implementation.  Figure  S.4  shows  the  part  of  the  tool  where  the  evaluator 
specifies  his  or  her  job  role,  and  the  risks  are  rated  across  all  five  attack  components. 
Readers  may  obtain  a  copy  of  this  prototype  online  at  www.rand.org/publications/ 
MR/MR1601/. 
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Figure  S.4 — User  and  Attack  Component  Filtering  in  the  VAM  Tool  (notional  values) 
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CONCLUSIONS 

The  VAM  methodology  provides  a  relatively  comprehensive,  top-down  approach  to 
information  system  security  with  its  novel  assessment  and  recommendation¬ 
generating  matrix  and  filtering  methods. 

The  vulnerabilities  and  security  taxonomies  are  fairly  complete.  Viewing  vulnerabil¬ 
ity  properties  separate  from  system  objects  has  proved  to  be  a  valuable  way  of 
reviewing  the  system  for  vulnerabilities,  since  the  properties  often  apply  to  each  type 
of  object.  Also,  each  object  type  plays  an  important  role  in  the  information  systems. 
The  realization  and  expansion  of  the  vulnerability  review  to  explicitly  consider  physi¬ 
cal,  human/social,  and  infrastructure  objects,  in  addition  to  cyber  and  computer 
hardware  objects,  recognize  and  accommodate  the  importance  of  all  these  aspects  of 
information  systems  to  the  proper  function  of  these  systems. 

VAM  fills  a  gap  in  existing  methodologies  by  providing  explicit  guidance  on  finding 
system  vulnerabilities  and  suggesting  relevant  mitigations.  Filters  based  on  vulner¬ 
abilities,  evaluator  type,  and  attack  component  help  to  improve  the  usability  of  the 
recommendations  provided  by  the  methodology. 

Providing  a  computerized  aid  that  executes  the  methodology  during  an  evaluation 
greatly  improves  the  usability  of  the  methodology,  especially  because  the  current 
approach  generates  many  more  suggestions  than  the  earlier  version  in  Anderson  et 
al.  (1999).  The  current  spreadsheet  implementation  in  Excel  has  the  benefit  of  being 
usable  by  the  large  number  of  personal  computer  users  who  already  have  the  Excel 
program  on  their  machines.  The  spreadsheet  also  gives  the  user  the  flexibility  to  gen¬ 
erate  analysis  reports  and  even  input  custom  rating  algorithms  to  accommodate 
local  needs  and  situations. 

The  methodology  should  be  useful  for  both  individuals  and  teams.  Individuals  can 
focus  on  their  specific  situation  and  areas  of  responsibility,  while  teams  can  bring 
multiple  kinds  of  expertise  to  bear  on  the  analyses,  as  well  as  perspectives  on  differ¬ 
ent  divisions  within  an  organization.  The  methodology  also  can  be  used  in  parallel  by 
different  divisions  to  focus  on  their  own  vulnerabilities  and  can  be  integrated  later  at 
a  high-level  review  once  each  group’s  justifications  and  mappings  back  to  the  orga¬ 
nization’s  functions  are  understood. 
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Chapter  One 

INTRODUCTION 


Many  organizations’  critical  functions  rely  on  a  core  set  of  information  system  capa¬ 
bilities.  Securing  these  capabilities  against  current  and  future  threats  requires  a 
broad  and  unbiased  view  of  system  vulnerabilities,  as  well  as  creative  consideration 
of  security  and  stability  options  in  the  face  of  resource  constraints.  Interoperability, 
information  sharing,  collaboration,  design  imperfections,  limitations,  and  the  like 
lead  to  vulnerabilities  that  can  endanger  information  system  security  and  operation. 
Unfortunately,  understanding  an  organization’s  reliance  on  information  systems,  the 
vulnerabilities  of  these  systems,  and  how  to  mitigate  the  vulnerabilities  has  been  a 
daunting  challenge — especially  for  less  well-known  or  even  unknown  vulnerabilities 
that  do  not  have  a  history  of  being  exploited. 

RAND  has  developed  and  evolved  a  methodology  to  help  analysts  understand  these 
relationships,  facilitate  the  identification  or  discovery  of  system  vulnerabilities,  and 
suggest  relevant  mitigation  techniques.  This  Vulnerability  Assessment  and  Mitiga¬ 
tion  (VAM)  methodology  builds  on  earlier  work  by  Anderson  et  al.  (1999);  it  fills  a 
much-needed  gap  in  existing  approaches  by  guiding  a  comprehensive  review  of  vul¬ 
nerabilities  across  all  aspects  of  information  systems  and  mapping  the  vulnerabilities 
to  specific  security  techniques  that  can  address  them. 

The  VAM  methodology  takes  a  top-down  approach  and  seeks  to  uncover  not  only 
vulnerabilities  that  are  known  and  exploited  or  revealed  today  but  also  the  vulner¬ 
abilities  that  exist  yet  have  not  been  exploited  or  encountered  during  operation. 
Thus,  the  methodology  helps  to  protect  against  future  threats  or  system  failures 
while  mitigating  current  and  past  threats  and  weaknesses.  Sophisticated  adversaries 
are  always  searching  for  new  ways  to  attack  unprotected  resources  (the  “soft  under¬ 
belly’’  of  the  information  systems);  thus,  the  methodology  can  be  valuable  as  a  way  to 
hedge  and  balance  current  and  future  threats.  Also,  the  complexity  of  information 
systems,  and  their  increasing  integration  with  organizational  functions,  requires 
additional  considerations  to  ensure  that  design  or  architectural  weaknesses  are  miti¬ 
gated. 

WHO  SHOULD  USE  THE  VAM  METHODOLOGY? 

This  report  should  be  of  interest  to  individuals  or  teams  conducting  vulnerability 
assessments  and  planning  mitigation  responses.  Because  it  facilitates  the  identifica¬ 
tion  of  new  vulnerabilities,  it  should  be  of  particular  interest  to  designers  building 
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new  systems,  as  well  as  to  security  specialists  concerned  about  highly  capable  and 
well-resourced  system  attackers,  such  as  nation-states  or  terrorists  motivated  to 
identify  new  security  holes  and  exploit  them  in  subtle  and  creative  ways.  The  VAM 
methodology  also  facilitates  a  comprehensive  review  of  known  vulnerabilities  in  bal¬ 
ance  with  new  vulnerabilities  so  the  user  can  determine  the  most  serious  problems 
and  address  them  in  a  rational  approach. 

The  methodology  provides  a  broad  view  of  vulnerability  sources  (either  commonly 
known  or  unrecognized  until  now),  system  objects,  and  security  alternatives  to  help 
avoid  prior  biases,  so  both  outside  assessors  and  people  within  an  organization 
should  find  it  useful.  However,  the  methodology  requires  both  objectivity  and 
knowledge  of  the  system  in  question;  therefore  outsiders  will  need  access  to  system 
experts,  while  insiders  will  need  to  approach  an  assessment  with  an  open  mind. 

We  also  found,  in  using  the  methodology  to  examine  operational  systems,  that  peo¬ 
ple  in  different  roles  in  an  organization  have  different  security  options  available  to 
them.  Thus,  designers,  operators,  and  policymakers  can  all  benefit  in  their  comple¬ 
mentary  use  of  the  methodology. 

Furthermore,  we  found  the  methodology  useful  in  examining  information  warfare 
concepts,  in  which  vulnerabilities  and  security  responses  of  information  systems  are 
important  considerations.  Thus,  the  methodology  may  also  be  of  interest  to  persons 
involved  in  other  aspects  of  information  operations  (10),  including  exploitation  and 
attack. 

PREVIOUS  RESEARCH 

In  1999,  Anderson  et  al.  at  RAND  published  Securing  the  U.S.  Defense  Information 
Infrastructure:  A  Proposed  Approach  (also  known  as  the  “MEII  Study”).  The  original 
goal  of  the  study  was  to  explore  the  concept  of  a  “minimum  essential  information 
infrastructure”  (MEII)  for  the  Department  of  Defense  (DoD).  The  report  outlined  a 
six-step  process  for  risk  reduction  in  critical  DoD  information  systems.  Its  main  con¬ 
tribution  was  a  listing  of  20  generic  areas  of  potential  vulnerability  in  complex  infor¬ 
mation  systems  used  for  command,  control  (C2)  and  intelligence.  It  also  listed  13 
general  areas  of  security  techniques  that  could  be  used  in  various  ways  to  mitigate 
these  vulnerabilities  and  provided  a  color-coded  matrix  showing  which  security 
techniques  tended  to  work  best  against  which  vulnerabilities.  The  earlier  study’s 
results  were  theoretical  and  had  not  yet  been  applied  to  a  real  system. 

In  November  2000,  Brian  Witten  of  the  Defense  Advanced  Research  Projects  Agency 
(DARPA)  suggested  that  the  original  study’s  framework  should  be  used  to  study  an 
operational  DoD  C2  system  to  assess  the  methodology’s  effectiveness  in  uncovering 
unexpected  sources  of  vulnerability  and  to  suggest  relevant  security  techniques  for 
their  mitigation.  That  follow-on  study  began  in  spring  2001.  This  report  is  one  of  two 
documents  resulting  from  that  work. 

During  the  course  of  the  study,  we  determined  that  the  earlier  methodology  (list  of 
vulnerabilities  mapped  to  a  list  of  security  techniques)  was  valuable;  however,  the 
lists  needed  updating  and  better  ways  were  needed  to  handle  the  large  amounts  of 
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security  suggestions  generated.  This  present  report  outlines  the  updated  and 
extended  methodology.  The  VAM  methodology  now  identifies  a  more  comprehen¬ 
sive  and  taxonomical  set  of  attributes  that  leads  to  vulnerabilities  and  the  security 
techniques  that  can  mitigate  them;  an  expanded  map  between  attributes  and 
security  techniques;  filters  that  refine  the  list  of  security  techniques  to  consider;  and 
a  software  tool  that  automates  table  and  filter  lookups,  along  with  additional 
informational  guidance. 

Unpublished  RAND  research  by  the  authors  of  this  report  explored  the  issues  and 
results  from  applying  the  VAM  methodology  to  military  tactical  information  systems. 
Because  this  study  contains  details  of  sensitive  information,  the  results  mentioned 
above  may  be  available  only  to  authorized  government  individuals  by  contacting 
Philip  Anton  (anton@rand.org)  or  Robert  Anderson  (anderson@rand.org).  However, 
the  nonsensitive  lessons  learned  from  that  application  study  are  incorporated  in  the 
methodology  described  below. 

STRUCTURE  OF  THIS  REPORT 

The  rest  of  this  report  is  organized  as  follows: 

Chapter  Two  defines  what  constitutes  an  information  system.  It  then  provides  a  con¬ 
ceptual  discussion  of  what  leads  to  vulnerabilities  and  introduces  concepts  that  help 
to  understand  vulnerabilities,  where  they  arise,  and  how  they  can  be  mitigated. 

Chapter  Three  provides  an  overview  of  the  six  steps  of  the  VAM  methodology  along 
with  a  notional  example.  The  chapter  also  describes  how  the  methodology  compares 
with  and  relates  to  other  security  methodologies.  Since  the  core  of  the  VAM 
methodology  involves  the  identification  of  vulnerabilities  and  the  selection  of  secu¬ 
rity  techniques  to  mitigate  them,  Chapters  Four  through  Seven  provide  details  of 
how  VAM  helps  the  user  accomplish  this. 

Chapter  Four  provides  an  in-depth  description  of  the  attributes  of  system  objects 
that  can  lead  to  vulnerabilities  (step  3  of  the  methodology)  and  examples  of  how  they 
combine  in  some  well-known  information  system  vulnerabilities. 

Chapter  Five  gives  an  in-depth  description  of  information  system  security  tech¬ 
niques  and  examples  of  how  they  combine  in  some  well-known  security  approaches. 

Chapter  Six  describes  how  the  VAM  methodology  maps  the  vulnerabilities  in  Chapter 
Four  to  the  security  techniques  in  Chapter  Five  to  provide  specific  guidance  on  how 
to  address  identified  vulnerabilities.  Next,  the  chapter  illustrates  filtering  techniques 
to  improve  the  appropriateness  of  the  security  techniques  identified  in  the  matrix  to 
the  particular  user  type  and  attack  stage.  Chapters  Five  and  Six  describe  step  4  of  the 
methodology  and  support  the  selection  of  security  techniques  (step  5).  Finally,  the 
chapter  provides  specific  examples  of  the  kinds  of  specific  security  countermeasures 
that  can  be  identified  for  specific,  common  information  system  vulnerabilities  by  an 
operational  evaluator  employing  the  methodology. 
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Chapter  Seven  describes  a  spreadsheet  implementation  of  the  VAM  methodology 
that  automates  looking  up  information  and  explanations  in  the  methodology. 

Chapter  Eight  discusses  some  deficiencies  in  the  current  VAM  methodology,  possible 
next  steps,  and  some  general  discussion. 

Chapter  Nine  presents  final  conclusions  and  perspectives. 

The  Appendix  contains  detailed  information  behind  the  ratings  in  the  matrix  that 
maps  vulnerabilities  to  candidate  security  techniques. 


Chapter  Two 

CONCEPTS  AND  DEFINITIONS 


Before  describing  the  content  and  processes  in  the  VAM  methodology,  we  need  to 
explore  the  underlying  concepts  and  terminology  it  employs:  What,  for  example, 
constitutes  an  information  system?  What  leaves  such  a  system  vulnerable  to  attack  or 
failure?  What  types  of  components  can  have  vulnerabilities? 

SECURITY 

“Security”  means  different  things  to  different  people,  depending  on  their  view  of 
what  can  lead  to  a  compromise  of  the  system  in  question.  We  take  a  broad  view  of 
security  to  include  any  issue  that  affects  the  safe  and  reliable  performance  of  the 
system.  Compromises  to  the  system  can  therefore  arise  not  only  from  overt  attacks 
by  adversaries  but  also  from  accidents,  faults,  failures,  limitations,  and  natural 
causes. 

INFORMATION  SYSTEMS 

We  use  the  term  “information  system”  quite  broadly  to  include  any  system  or  com¬ 
ponent  (whether  physical,  cyber,  virtual,  computer,  communication,  human,  or 
social)  that  is  involved  in  storing,  processing,  handling,  or  transmitting  information. 
While  the  scope  of  an  information  processing  system  can  be  defined  more  narrowly 
(i.e.,  purely  by  computer  software  and  hardware),  we  are  often  concerned  with  the 
information-related  functions  of  and  for  organizations.  Anything  that  can  lead  to 
failure  in,  or  compromise  of,  an  information  system  component  can  endanger  the 
performance  of  the  organization  and  its  mission,  thus  imploring  consideration  when 
securing  the  system. 

SYSTEM  OBJECT  TYPES 

We  explicitly  represent  the  different  types  of  system  components  according  to 
whether  they  are  physical,  cyber,  human/ social,  or  enabling  infrastructure. 

Physical.  These  objects  include,  for  example,  hardware  (e.g.,  data  storage, 
input/output  [I/O],  clients,  and  servers),  networks  and  communications  between 
and  within  nodes,  and  physical  locations  at  various  levels  within  the  system’s  archi¬ 
tecture. 
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Cyber.  Cyber  objects  include,  for  example,  software,  data,  information,  and  knowl¬ 
edge.  Often  they  exist  “virtually”  in  electronic  or  even  conceptual  representations 
that  are  far  removed  from  the  physical  forms  or  media  (e.g.,  disks,  paper,  binary 
switches)  in  which  they  exist. 

Human/Social.  Human  and  social  objects  include,  for  example,  users  and  other  staff, 
developers,  management,  command  structures,  policies,  procedures,  training,  and 
authentication. 

Enabling  Infrastructure.  Infrastructures  include,  for  example,  physical  housings 
(e.g.,  buildings,  vehicles),  power,  water,  air,  and  other  environmental  conditionings. 

The  scope  of  this  object  list  allows  a  more  comprehensive  examination  of  all  the 
objects  in  a  system,  not  merely  the  computer  hardware  and  software  (which  are  so 
often  focused  on).  For  example,  information  is  processed  and  handled  by  humans 
within  an  organization,  not  just  by  computers  and  networks.  In  fact,  human  process¬ 
ing  of  information  is  a  key  component  in  information  systems,  and  the  vulnerability 
of  human  and  social  systems  must  be  addressed  during  a  comprehensive  evaluation 
of  risks. 

On  the  Use  of  the  “Object”  Concept 

The  use  of  an  “object”  is  a  common  theoretical  tool  in  information  science  that 
allows  one  to  address  a  person,  place,  or  thing  while  elucidating  its  properties  or 
behaviors  of  interest.  The  partitioning  of  information  system  components  into  con¬ 
ceptual  “objects”  allows  us  to  emphasize  components  that  are  often  neglected  when 
considering  security.  Cyber  objects  are  automated,  computerized,  software,  or  virtual 
components  that  are  normally  considered  as  the  components  of  information  sys¬ 
tems.  However,  these  objects  usually  occupy  and  rely  on  physical  objects  as  well  (e.g., 
the  physical  devices  that  instantiate  virtual  objects,  the  buildings  in  which  the 
devices  reside,  or  the  physical  spectra  that  they  exploit).  Human  beings  are  other 
“objects”  that  process  information  in  the  system;  they  use,  manage,  and  control  the 
system,  its  objects,  and  its  goals.  Humans  exist  in  multiple  social  structures  that 
influence  their  behavior.  Finally,  all  three  of  these  types  of  objects  rely  on  infrastruc¬ 
ture  components  that  are  not  formally  part  of  the  information  system  yet  supply  vital 
support  to  the  system  (e.g.,  power,  air,  food,  temperature  control). 

ATTRIBUTES  AS  SOURCES  OF  VULNERABILITIES 

Vulnerabilities  arise  from  identifiable  attributes  of  information  system  objects.  The 
VAM  methodology  explores  this  genesis  explicitly,  providing  a  relatively  comprehen¬ 
sive,  high-level  review  of  vulnerabilities  from  first  principles  and  mapping  them 
across  all  object  types.  This  approach  guides  the  evaluator  to  examine  all  vulnera¬ 
bilities — not  just  the  ones  that  are  known  or  have  been  exploited  to  date — and 
explores  the  vulnerabilities  across  all  the  system’s  objects — not  just  the  cyber-related 
components. 
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Anderson  et  al.  (1999)  first  explored  the  concept  of  information  system  vulnerabili¬ 
ties  arising  from  attributes  of  the  information  system.  Our  work  builds  on  these  con¬ 
cepts  by  explicitly  separating  the  objects  from  the  attributes  they  exhibit  and  expand¬ 
ing  the  list  of  attributes  that  lead  to  vulnerabilities. 

Separating  vulnerability  attributes  from  system  object  types  encourages  the  exami¬ 
nation  of  potential  vulnerabilities  from  applying  attributes  normally  associated  with 
certain  object  types  to  other  types  of  objects  in  the  system.  For  example,  singularities 
can  be  present  not  only  in  cyber  software  or  physical  hardware  but  also  in  unique, 
irreplaceable  people  (users)  who  alone  know  how  to  operate  certain  equipment  or 
process  certain  types  of  information. 

Security  Techniques 

Finally,  we  handle  the  vast  number  of  security  techniques  in  use  or  under  research 
by  the  information  security  community  by  categorizing  them  according  to  the 
approach  they  take  to  mitigate  vulnerabilities.  Thus,  we  can  methodologically  treat 
these  techniques  in  the  abstract  and  describe  how  they  relate  to  the  vulnerabilities 
they  mitigate.  Techniques  in  each  category  are  listed  in  Chapter  Five.  The  categories 
are  not  of  equal  size;  historically,  more  attention  has  been  paid  to  some  techniques 
than  to  others.  In  some  cases,  this  skew  is  quite  logical;  in  other  cases,  there  are  new 
techniques  that  provide  important  promise  and  deserve  added  attention  in  the 
future.  Considering  the  techniques  by  approach  type  helps  in  looking  for  the  best 
technique  that  logically  meets  a  vulnerability  challenge,  without  getting  unduly  dis¬ 
tracted  by  their  differences. 


Chapter  Three 

VAM  METHODOLOGY  AND  OTHER  DoD  PRACTICES  IN 

RISK  ASSESSMENT 


OVERVIEW  OF  THE  VAM  METHODOLOGY 

In  the  late  1990s,  RAND  published  a  six-step  methodology  to  improve  the  security 
posture  of  critical  information  systems  (Anderson  et  al.,  1999).  The  steps  were  to 

1.  Identify  your  organization’s  essential  information  functions. 

2.  Identify  information  systems  essential  to  implementing  the  essential  functions  in 
step  1. 

3.  Identify  vulnerabilities  of  the  essential  systems  in  step  2. 

4.  Identify  pertinent  security  techniques  to  mitigate  the  vulnerabilities  in  step  3 
using  the  VAM  matching  matrix  tool. 

5.  Select  and  apply  techniques  from  step  4  based  on  constraints,  costs,  and  benefits. 

6.  Test  the  techniques  applied  in  step  5  for  robustness  and  actual  feasibilities  under 
threat. 

Repeat  steps  3-6  as  needed. 

Note  in  particular  that  the  methodology  includes  an  explicit  mapping  of  vulnerabili¬ 
ties  to  security  techniques  (step  4).  This  mapping  forms  the  core  of  the  methodology 
and  provides  the  evaluator  with  explicit  guidance  on  addressing  the  vulnerabilities. 
The  current  work  in  this  report  expands  the  size  and  complexity  of  this  matrix  to 
improve  the  comprehensiveness  of  the  matrix  approach. 

We  give  an  overview  below  of  how  this  six-step  process  works,  along  with  a  concep¬ 
tual  military  example  of  its  use.  Even  though  we  illustrate  the  basic  steps  using  a  mili¬ 
tary  example,  the  VAM  methodology  can  be  applied  to  other  critical  commercial  and 
government  functions  as  well. 

The  most  involved  parts  of  the  VAM  methodology  are  found  in  steps  3  and  4  (the 
identification  of  vulnerabilities  and  the  generation  of  security  techniques  to  mitigate 
them).  Chapters  Four  through  Seven  provide  additional  details  on  the  steps  beyond 
what  is  included  here. 
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Step  1.  Identify  Essential  Information  Functions 

Information  systems  are  not  ends  in  themselves.  They  are  employed  by  individuals 
and  organizations  to  support  specific  functions  and  operations.  Given  limited 
resources,  security  vulnerabilities  that  endanger  the  essential  information-based 
functions  should  be  addressed  first.  Thus,  an  individual  trying  to  identify  and  miti¬ 
gate  these  vulnerabilities  first  needs  to  distinguish  what  the  essential  functions  are. 

Process.  An  objective  process  can  guide  the  identification  of  an  organization’s 
essential  information  functions. 

First,  a  strategies-to-tasks  analysis  (Lewis  and  Roll,  1993;  Thaler,  1993;  Kent  and 
Simons,  1994)  can  be  conducted.  Here  the  goals  and  strategies  of  the  organization 
are  identified  and  prioritized,  and  the  strategies  are  mapped  to  the  tasks  (functions) 
designed  to  implement  the  strategies. 

Second,  specific  information  functions  in  support  of  these  tasks  are  identified  and 
categorized. 

Third,  measures  of  essentiality  are  developed  and  employed  to  rank  the  information 
functions  into  the  following  categories:  essential,  valuable,  and  expendable.  Essential 
functions  are  those  that,  if  compromised,  prevent  the  organization  from  performing 
its  important  tasks  satisfactorily  (as  defined  by  the  strategy-to-tasks  requirements). 
Valuable  functions  are  those  in  which  work-arounds  can  be  identified;  yet  the  work¬ 
arounds  have  significant  performance  costs  and  risks.  Expendable  functions  are 
those  in  which  work-arounds  with  acceptable  performance  costs  and  risks  can  be 
identified. 

Finally,  all  the  identified  functions  are  integrated  to  develop  an  overall  ranking  of 
information  functions.  Special  attention  should  be  paid  to  looking  for  functions 
essential  or  valuable  to  many  or  all  tasks.  Also,  sets  or  logical  groupings  of  functions 
that  support  numerous  tasks  should  be  identified  where  possible,  thus  identifying 
regions  of  functionality  that  require  particular  attention. 

Example.  In  an  example  of  notionally  applying  the  methodology  to  a  military  organi¬ 
zation,  a  joint  force  air  component  commander  (JFACC)1  performs  a  number  of  func¬ 
tions  in  the  execution  of  an  air  campaign,  including  generating  and  distributing  an 
air  tasking  order  (ATO), 2  analyzing  logistics  support  needs,  planning  fuel  resource 
allocations,  planning  medical  operations,  and  teleconferencing  with  other  military 


1DoD  defines  a  JFACC  as 

The  commander  within  a  unified  command,  subordinate  unified  command,  or  joint  task  force  responsible  to  the 
establishing  commander  for  making  recommendations  on  the  proper  employment  of  assigned,  attached,  and/or 
made  available  for  tasking  air  forces;  planning  and  coordinating  air  operations;  or  accomplishing  such 
operational  missions  as  may  be  assigned.  The  joint  force  air  component  commander  is  given  the  authority 
necessary  to  accomplish  missions  and  tasks  assigned  by  the  establishing  commander. . . .  (Joint  Chiefs  of  Staff 
[2003]) 

See  also  Joint  Chiefs  of  Staff  (1994)  for  details  on  the  roles  of  the  JFACC  in  military  air  planning. 

2During  military  operations,  an  ATO  specifies  which  aircraft  are  assigned  which  tasks  (e.g.,  conducting 
patrols,  dropping  munitions  on  specific  targets,  providing  troop  and  supply  transport). 
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planners  (see  Figure  3.1).  Of  all  the  functions  listed,  the  generation  and  distribution 
of  the  ATO  (in  the  solid  oval)  could  arguably  be  selected  as  the  critical  function  that 
must  be  supported  in  the  near  term.  The  other  functions  are  less  time-critical  and 
serve  secondary  support  to  the  generation  (and  ultimately  execution)  of  the  ATO. 
Thus,  we  select  the  generation  and  distribution  of  the  ATO  as  the  “essential  informa¬ 
tion  function”  for  the  JFACC  organization. 


Step  2.  Identify  Essential  Information  Systems 

Given  the  essential  information-related  functions  from  step  1,  the  essential  informa¬ 
tion  systems  that  support  or  implement  these  functions  now  need  to  be  identified. 

Process.  First,  the  information  systems  used  to  perform  the  essential  functions 
identified  in  step  1  need  to  be  identified  and  categorized.  These  systems  form  the  list 
of  candidate  “essential”  information  systems. 

Again,  measures  of  essentiality  are  developed  and  employed  to  rank  the  information 
systems  as  essential,  valuable,  or  expendable.  Finally,  all  the  identified  systems  are 
integrated  across  the  functions  to  develop  an  overall  ranking  of  information  systems. 
Special  attention  should  be  paid  to  looking  for  systems  critical  to  many  or  all 
functions.  Also,  sets  or  logical  groupings  of  systems  that  support  numerous  functions 
should  be  identified  where  possible,  thus  identifying  logical  sets  of  systems  that 
require  particular  attention. 

Example.  In  our  continuing  example,  if  located  on  a  ship,  a  JFACC  and  his  or  her  staff 
employ  a  number  of  information  systems  to  support  their  operations.  These  infor¬ 
mation  systems  include  the  Global  Command  and  Control  System-Maritime  (GCCS- 
M),  the  Global  Combat  Support  System  (GCSS)  for  logistics,  the  so-called  Common 
Operating  Environment  (COE)  supplied  on  many  general-purpose  military  comput¬ 
ers,  the  Secure  Internet  Protocol  Router  Network  (SIPRNet),  and  the  public  switched 
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Figure  3.1 — Example  Functional  Decomposition  of  JFACC  Information  Functions 
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telephone  network  (see  Figure  3.2).  Because  step  1  identified  the  generation  and  dis¬ 
semination  of  an  ATO  as  the  essential  function,  we  need  to  select  the  essential  infor¬ 
mation  systems  that  support  that  function.  GCCS-M  and  SIPRNet  (in  solid,  bold 
boxes)  are  the  essential  information  systems  that  support  the  ATO.  Of  these  two  sys¬ 
tems,  and  from  the  perspective  of  passing  information  to  the  JFACC  for  processing, 
SIPRNet  could  be  identified  as  the  main  information  communication  backbone  that 
is  most  essential  to  support  the  ATO  generation  and  dissemination  function;  yet 
GCCS-M  is  also  essential  for  rapid  ATO  generation. 

Step  3.  Identify  System  Vulnerabilities 

Given  the  prioritized  list  of  essential  information  systems  from  step  2,  we  can  now 
focus  on  examining  the  systems  for  vulnerabilities.  This  is  the  step  in  which  the  VAM 
methodology  uniquely  begins  to  contribute  advice,  since  many  other  methodologies 
lack  specific  help  in  determining  vulnerabilities.  Note  that  a  successful  vulnerability 
assessment  requires  the  insights  and  experience  of  system  users  and  developers  as 
outlined  below;  so  both  methodological  guidance  and  experience  are  important. 

ffere  we  describe  the  process  involved  in  step  3,  along  with  a  notional  example. 
Chapter  Four  details  how  this  assessment  is  conducted  from  an  objective,  top-down 
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Figure  3.2 — Example  Information  Systems  Supporting  the  JFACC  Information  Functions 
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perspective  of  inherent  attributes  that  lead  to  vulnerabilities,  including  additional 
details  on  the  vulnerability  form,  specific  vulnerability  attributes,  and  the  distinction 
of  attributes  from  system  object  types.  Specific  examples  of  common  vulnerabilities 
are  included  in  Chapter  Four  and  at  the  end  of  Chapter  Six. 

Process.  The  VAM  methodology  takes  a  broad  approach  to  vulnerability  analysis  by 
asking  the  evaluator  to  complete  a  matrix  containing  a  relatively  comprehensive  tax¬ 
onomy  of  attributes  that  lead  to  vulnerabilities  across  all  types  of  system  objects  (see 
the  schematic  in  Table  3.1). 

Vulnerabilities  should  be  reviewed  at  various  levels  within  a  system.  For  example,  a 
cyber  object’s  vulnerabilities  should  be  reviewed  at  the  global  architecture  level  (e.g., 
major  systems,  their  interactions,  and  the  systems  that  provide  global  communica¬ 
tion  of  data);  application  components  in  the  architecture  (i.e.,  specific  applications 
ranging  from  commercial  software  components  to  custom  applications  designed  to 
meet  the  unique  processing  needs  of  the  organization’s  users);  common  supporting 
software  (e.g.,  database  software,  encryption/ decryption  packages,  support  li¬ 
braries);  communication-level  components  (e.g.,  software  that  interfaces  directly 
with  communication  lines),  and  so  on.  The  goal  is  to  review  the  components  that  are 
key  to  the  system’s  proper  and  reliable  operation  no  matter  what  the  level,  yet 

Table  3.1 

Vulnerability  Matrix:  Attributes  of  Information  System  Objects 
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Infrastructure 
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Design/ 
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judgments  of  the  criticality  are  important  lest  the  user  get  buried  in  noncritical 
details. 

Along  with  the  vulnerability  taxonomy,  the  evaluator  should  review  past  experience 
with  the  critical  systems,  asking  the  following  questions: 

•  What  has  failed  in  the  past?  Why? 

•  What  has  been  the  effect  of  these  failures? 

•  What  corrective  actions  have  been  tried? 

Efforts  should  be  made  to  explain  these  experiences  with  theoretical  models.3  If  the 
experiences  are  consistent  with  the  models,  then  the  evaluator  should  gather  statis¬ 
tics  on  the  failures  to  help  identify  which  have  been  more  serious  in  the  past.  If  the 
models  are  insufficient,  then  the  evaluator  should  attempt  to  refine  or  extend  the 
models  or  find  other  models  that  may  help  to  reveal  the  underlying  reasons  why  fail¬ 
ures  have  been  occurring.  These  models  need  not  be  detailed,  but  they  should  help 
to  identify  which  vulnerability  attributes  have  been  leading  to  failure  and  which  are 
present  in  the  system. 

The  evaluator  can  also  look  for  vulnerabilities  by  examining  the  security  techniques 
already  employed  in  the  system  and  considering  the  vulnerability  cautions  identified 
in  the  matrix  in  step  4  below  associated  with  these  security  techniques. 

Finally,  the  evaluator  needs  to  assess  what  theoretical  vulnerabilities  are  in  the  sys¬ 
tem  for  which  there  is  no  real-world  or  test  experience.  The  evaluator  should  review 
the  system’s  components,  with  the  full  list  of  vulnerability  attributes,  as  a  checklist. 
The  presence  of  such  attributes  represents  a  potential  vulnerability  that  needs  to  be 
investigated  further  to  determine  how  serious  the  vulnerability  may  be.  Again,  theo¬ 
retical  models  of  system  function  may  be  useful  to  explore  and  explain  the  role  these 
attributes  may  play  in  potential  compromises  or  failures.  Statistics  may  or  may  not 
be  available,  but  the  space  of  plausible  threats  or  failures  should  be  examined  to 
assess  the  significance  of  the  potential  vulnerability  against  important  capabilities  of 
the  information  system. 

Example.  Considering  GCCS-M  and  SIPRNet,  identified  in  step  2,  we  ask  what  the 
critical  vulnerabilities  are  that  we  need  to  address  to  support  these  information  sys¬ 
tems  (see  Figure  3.3).  Identification  of  specific  vulnerabilities  for  these  military  sys¬ 
tems  is  beyond  the  scope  of  this  report,  so  we  treat  vulnerabilities  in  the  abstract. 
Notionally,  we  work  through  the  potential  types  of  vulnerabilities  and  identify  that 
GCCS-M  contains  vulnerabilities  E  and  F.  If  security  technique  3  is  already  employed 
in  GCCS-M,  the  user  then  should  also  see  if  vulnerability  Tis  present  (see  Figure  3.4). 
Remember  that  we  need  to  search  for  these  vulnerabilities  at  the  various  levels  of 


3For  example,  some  intrusion  detection  systems  use  models  of  “normal”  communication  behavior  to  look 
for  such  outliers  as  heavy  communication  from  a  particular  piece  of  software  or  machine  that  has  histori¬ 
cally  had  very  low  communication.  Other  models  may  be  as  simple  as  anticipated  component  failure  rate 
curves  against  which  data  can  be  collected  to  locate  abnormal  failure  rates.  Still  other  models  may  be 
security  profile  models  of  staff  that  can  be  used  in  background  checks  to  help  identify  possible  staff  com¬ 
promises  or  behavior  patterns  that  may  lead  to  weaknesses  and  problem  behavior. 
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GCCS-M;  so,  we  should  examine  GCCS-M  as  a  whole,  its  primary  applications,  and 
the  critical  supporting  components  (e.g.,  SIPRNet).  Within  SIPRNet,  various  levels 
need  examination,  including  the  government  and  commercial  software  used,  the 
communication  systems,  the  networking  system  and  routers,  the  administrative 
operators,  and  the  physical  components,  such  as  cabling  and  critical  supporting 
infrastructure. 

Step  4.  Identify  Pertinent  Security  Techniques  from  Candidates  Given  by 
the  VAM  Methodology 

Identifying  vulnerabilities  can  be  a  difficult  task,  but  determining  how  to  address 
them  can  be  even  more  difficult  and  frustrating.  The  VAM  methodology  provides  a 
theoretical  mapping  not  only  to  help  prioritize  the  mitigation  techniques  that  natu¬ 
rally  come  to  mind  but  also  to  provide  a  relatively  comprehensive  review  of  other 
techniques  that  may  not  be  obvious  initially. 

Process.  The  VAM  methodology  contains  a  large  matrix  that  identifies  general  secu¬ 
rity  techniques  relevant  to  each  vulnerability.  The  matrix  also  identifies  cautions 
where  the  security  technique  might  incur  an  additional  vulnerability.  A  schematic  of 
the  matrix  is  included  in  the  example  below,  illustrating  how  the  matrix  is  used  to 
identify  potential  security  techniques  that  address  the  vulnerabilities  of  concern. 

RANDMR1601-3.3 

Global  Command  and 
Control  System-M 


Potential 

vulnerabilities: 


l  Vulnerability  A 

l  Vulnerability  B 

l  Vulnerability  C 

l  Vulnerability  D 

l - ►  Vulnerability  E 

1 - ►  Vulnerability  F 


Figure  3.3 — Identifying  Which  Vulnerabilities  Apply  to  the  Critical  System 
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Chapters  Six  and  Seven  describe  this  matrix  in  detail,  along  with  usability  issues  and 
a  spreadsheet  implementation  that  automates  the  security  technique  candidate 
lookups. 

Example.  In  step  3,  vulnerabilities  E  and  F  were  identified  as  the  critical  notional 
vulnerabilities  for  GCCS-M.  Figure  3.4  gives  a  notional  diagram  of  the  VAM  table  that 
maps  these  vulnerabilities  to  appropriate  mitigation  techniques.  In  our  example, 
techniques  2  and  4  are  the  primary  techniques  that  may  address  vulnerabilities  E  and 
F  (respectively).  Techniques  2  and  3  are  alternates,  secondary  techniques  that  may 
address  vulnerability  F.  Thus,  we  examine  techniques  2  and  4  first  to  see  if  they  fit  the 
needs  of  GCCS-M.  If  they  do  not,  we  then  consider  technique  3. 

The  map  also  identifies  vulnerability  side  effects  that  may  be  incurred  from  the 
employment  of  a  mitigation  technique.  Here,  technique  3  may  introduce  vulnerabil¬ 
ity  T  in  some  cases,  so  a  caution  is  noted  to  watch  for  the  incursion  of  vulnerability  T 
if  technique  3  is  implemented. 

Since  this  example  is  quite  notional,  the  reader  may  wish  to  see  the  end  of  Chapter 
Six  for  concrete  examples  of  security  techniques  developed  for  some  common 
information  system  vulnerabilities. 

Step  5.  Select  and  Apply  Security  Techniques 

Process.  The  list  of  appropriate  security  techniques  identified  in  step  4  must  now  be 
culled  down  to  a  set  that  can  be  implemented  given  the  available  resources  and 
responsibilities  of  the  evaluator’s  organization.  While  the  evaluator  can  apply  some 
techniques  directly,  other  techniques  may  be  out  of  the  purview  of  the  evaluator  and 
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Figure  3.4 — The  Concept  of  Mapping  Vulnerabilities  to  Security  Mitigation  Techniques 
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his  or  her  organization.  In  the  latter  case,  promising  approaches  in  this  category  can 
be  passed  along  to  responsible  parties.  Also,  the  large  number  of  options  generated 
by  the  matrix  can  suggest  other  areas  that  may  not  have  been  the  most  obvious  or 
direct,  yet  that  may  reduce  the  vulnerability  of  the  system.  For  example,  manage¬ 
ment,  counterintelligence  (Cl),  and  retribution  measures  can  help  protect  the  system 
and  deter  attacks  when  software  changes  and  protection  programs  are  not  options  to 
user  communities. 

Example.  In  the  example  case  of  GCCS-M,  we  then  apply  techniques  2,  3,  and  4  to 
bolster  GCCS-M  (see  Figure  3.5). 

Step  6.  Test  for  Robustness  Under  Threat 

Simply  adding  more  security  techniques  does  not  necessarily  imply  that  the  prob¬ 
lems  have  been  resolved.  The  improved  system  should  be  tested  under  actual  or 
simulated  threat  conditions  to  determine  how  effective  the  mitigation  has  been.  Vul¬ 
nerability  information  from  such  testing  can  be  applied  back  into  step  3  to  help 
determine  other  security  options  to  consider  and  apply. 

Process.  Test  the  effectiveness  of  the  improved  system.  Red  teaming  is  an  important 
approach  for  such  testing  because  it  provides  an  independent  examination  of  vul¬ 
nerabilities  and  robustness.  These  teams  should  not  only  test  against  known  prob¬ 
lems  and  fixes  but  also  look  for  and  identify  new  problems  (including  any  introduced 
inadvertently  with  the  newly  added  security  techniques).  Residual  concerns  should 
be  addressed  in  realistic  exercises  (or  sometimes  in  operational  settings  if  appropri¬ 
ate)  to  test  procedures  and  work-arounds. 

Other  test  approaches  may  also  be  useful.  The  security  implementers  (or  indepen¬ 
dent  parties  or  companies)  that  specialize  in  security  assessments  could  also  conduct 
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Figure  3.5 — Identifying  Security  Techniques  to  Consider 
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an  inspection  and  validation  of  the  implementation.  If  failure  or  compromise 
statistics  were  utilized  in  step  3,  these  values  could  be  compared  with  post¬ 
implementation  statistics  over  a  sufficiently  long  or  utilized  period  to  quantify  the 
success  of  the  mitigations.  In  some  cyber  parts  of  the  system,  automated  attack  or 
usage  tools  could  be  implemented  to  explore  how  well  the  system  responds  under 
simulated  attacks.  Note,  however,  that  many  automated  tools  are  limited  to  com¬ 
mon,  well-known,  and  previously  exploited  vulnerabilities.  Thus,  they  do  not  in 
general  address  the  full  breadth  of  system  components,  especially  when  physical, 
human/social,  and  infrastructure  components  are  not  stressed. 

The  best  test  procedures  will  incorporate  a  model  of  the  threat  to  assess  the  probabil¬ 
ity  of  the  threat  successfully  compromising  the  system.  These  models  should  be 
broad  enough  to  incorporate  both  the  threat’s  ability  to  discover  a  previously  unex¬ 
ploited  vulnerability  and  the  threat’s  technical  ability  to  exploit  the  vulnerability. 

The  tests  may  focus  on  the  part  of  the  system  that  has  been  modified,  but  secondary 
and  tertiary  effects  on  the  rest  of  the  system  and  other  functions  need  consideration. 

Finally,  the  results  of  the  tests,  along  with  the  previous  five  steps,  should  be  docu¬ 
mented  and  assessed  to  determine  if  additional  work  is  needed  starting  with  step  3. 

Example.  In  our  example,  a  (simulated)  threat  is  applied  to  GCCS-M  to  ascertain  its 
robustness  (see  Figure  3.6). 

OTHER  DoD  VULNERABILITY  ASSESSMENT  METHODOLOGIES 

Many  methodologies  and  assessment  techniques  are  used  by  the  commercial  sector 
and  by  DoD  to  identify  vulnerabilities  and  design  security  activities.  We  describe 
briefly  some  of  the  more  common  ones  below  and  discuss  how  the  VAM  methodol¬ 
ogy  relates  to  them. 
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Figure  3.6 — Test  the  Revised  System  Against  (Simulated)  Threats 
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OCTAVE 

The  Operationally  Critical  Threat,  Asset,  and  Vulnerability  Evaluation™  (OCTAVE™) 
is  a  framework  created  by  the  Software  Engineering  Institute  at  Carnegie  Mellon 
University  for  identifying  and  managing  information  security  risks  (Alberts  et  al., 
1999,  2001).4It  defines  a  set  of  processes  for  identifying  important  organizational 
missions,  threats  to  organizations,  and  vulnerabilities  that  the  threats  may  exploit. 
OCTAVE  also  includes  processes  for  developing  protection  strategies  to  reduce  the 
risks  from  these  vulnerabilities  and  threats.  The  framework  is  laid  out  in  the  follow¬ 
ing  set  of  “Processes”  (see  Alberts  etal.,  1999): 

1 .  Identify  enterprise  knowledge. 

2.  Identify  operational  area  knowledge. 

3.  Identify  staff  knowledge. 

4.  Establish  security  requirements. 

5.  Map  high-priority  information  assets  to  information  infrastructure. 

6.  Perform  infrastructure  vulnerability  evaluation. 

7.  Conduct  multidimensional  risk  analysis. 

8.  Develop  protection  strategy. 

OCTAVE  is  heavily  process  oriented,  helping  an  evaluator  structure  a  project  to  ana¬ 
lyze  and  mitigate  information  security  risks.  These  process  guidelines  can  play  a 
valuable  role  in  organizing  the  activity,  but  processes  6  and  8  do  not  have  a  system 
for  reviewing  the  fundamentals  that  lead  to  vulnerabilities.  Also,  these  processes  do 
not  produce  recommended  protection  strategies  relevant  to  the  identified  vulnera¬ 
bilities.  Thus,  the  VAM  methodology  complements  the  OCTAVE  framework.  An  eval¬ 
uator  may  benefit  from  the  combined  use  of  both  approaches. 

ISO/IEC  15408:  Common  Criteria 

International  Standard  15408,  the  Common  Criteria  for  Information  Technology 
Security  Evaluation  (or  “CC”  for  short),  is  a  guideline  that  indicates  which  system 
aspects  should  be  addressed  in  which  categories  of  processes  when  evaluating  the 
security  of  information  technology  (IT)  products  and  systems.5-6  The  CC  is  meant  to 
be  relevant  for  “consumers,”  “developers,”  and  “evaluators”  of  information  systems 
and  components.  The  CC  states  that  any  security  analysis  should  examine  the  physi- 


4A1so  see  the  OCTAVE  website  at  www.cert.org/octave/. 

5See  www.commoncriteria.org  for  details  on  the  standard  and  its  history. 

6CC  evolved  from  the  Trusted  Computer  System  Evaluation  Criteria  (TCSEC)  developed  in  the  United 
States  in  the  1980s.  In  the  early  1990s,  Europe  developed  the  Information  Technology  Security  Evaluation 
Criteria  (ITSEC)  built  on  the  concepts  of  the  TCSEC.  In  1990,  the  International  Standards  Organization 
(ISO;  www.iso.ch)  sought  to  develop  a  set  of  international  standard  evaluation  criteria  for  general  use.  The 
CC  project  was  started  in  1993  to  bring  all  these  (and  other)  efforts  together  into  a  single  international 
standard  for  IT  security  evaluation.  ISO  formally  accepted  CC  as  International  Standard  15408  in  1999. 
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cal  environment  a  system  will  exist  in,  the  assets  requiring  protection,  and  the  pur¬ 
pose  of  the  system  to  be  evaluated  (“target  system’’).  It  then  mandates  a  listing  of  the 
assumptions,  threats,  and  organizational  security  policies,  leading  to  a  set  of  security 
objectives  to  be  met.  Using  these  objectives,  a  set  of  security  requirements  should  be 
generated,  including  functional  and  assurance  requirements  as  well  as  requirements 
for  the  environment  within  which  the  target  system  will  operate.  Requirements  that 
recur  in  various  systems  and  settings  become  the  “protection  profile"  (PP),  which  is 
intended  to  be  reusable  and  defines  the  target  system’s  security  requirements 
“known  to  be  useful  and  effective  in  meeting  the  identified  objectives,  both  for  func¬ 
tions  and  assurance.  The  PP  also  contains  the  rationale  for  security  objectives  and 
security  requirements.”7  Evaluations — including  various  types  of  penetration  test¬ 
ing — should  then  be  carried  out  to  determine  a  level  of  compliance  with  the  PP. 

The  CC  guidelines  are  complex,  embodying  many  hundreds  of  pages  of  documenta¬ 
tion.  Much  of  the  vulnerability  analysis  within  the  process  is  based  on  the  developer’s 
vulnerability  analysis,  which  is  then  examined  by  an  evaluator  to  determine  com¬ 
pleteness  and  whether  “appropriate  measures  are  in  place  to  prevent  the  exploita¬ 
tion  of  obvious  vulnerabilities  in  the  intended  environment.”8  Other  tables  and 
charts  allow  an  evaluator  to  calculate  the  “attack  potential”  of  a  target  system  based 
on  the  elapsed  time  it  would  take  to  perform  a  successful  attack,  the  expertise 
required,  the  knowledge  of  the  target  system  available,  the  access  required,  and  the 
equipment  needed. 

We  cannot  do  justice  here  to  the  CC  framework,  nor  is  it  our  intent  to  critique  it.  We 
do  not  find  within  the  published  materials,  however,  much  guidance  for  developers 
and  others  regarding  where  within  the  complex  architecture  of  an  information  sys¬ 
tem  one  should  look  for  potential  vulnerabilities,  how  to  look  for  them  in  a  method¬ 
ological  way,  and  which  security  techniques  are  most  applicable  in  mitigating  any 
flaws  found.  We  believe  the  concepts  and  listings  in  the  VAM  methodology  could  be  a 
useful  augmentation  to  the  CC  process  in  all  these  areas. 

ISO/IEC  17799:  Code  of  Practice  for  Information  Security  Management 

International  Standard  177999  arose  from  the  British  Standard  7799  on  information 
security  management.  It  is  increasingly  used  as  a  substantial  checklist  for  ensuring 
that  information  security  practices  are  in  place  within  an  organization.  It  covers 
many  relevant  aspects  for  information  security  management,  including  the  follow¬ 
ing: 


•  security  policy  (in  a  documented  form) 

•  organization  security  (within  the  organization,  the  security  of  third-party  access, 
and  security  of  outsourcing  procedures) 


7See  Common  Criteria  (1999a,  p.  28). 

8See  Common  Criteria  (1999e,  p.  365). 

9First  edition  dated  December  12,  2000. 
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•  asset  classification  and  control 

•  personnel  security,  including  appropriate  job  definitions,  user  training,  and 
response  procedures 

•  physical  and  environmental  security 

•  communications  and  operations  management 

•  access  controls,  including  monitoring  system  access  and  use  and  security  of 
mobile  computing  (e.g.,  wireless)  access 

•  systems  development  and  maintenance 

•  compliance  procedures. 

The  thoroughness  of  this  set  of  categories  is  admirable,  but  each  is  treated  quite 
superficially  within  the  standard  itself.  The  checklist  within  the  standard  is  a 
reminder  of  “best  practices’’  resulting  from  experience  with  secure/insecure  infor¬ 
mation  systems,  but  the  standard  does  not  give  much  guidance  in  understanding  the 
levels  of  threats  faced  and  where  vulnerabilities  may  lurk,  which  are  the  underlying 
motivations  for  this  guidance.  We  have  used  the  list  of  security  management  tech¬ 
niques  in  this  standard  as  one  of  the  sources  consulted  in  developing  our  list  of 
security  mitigation  techniques  (see  Chapter  Five). 

Operations  Security 

Operations  Security  (OPSEC)  as  a  methodology  originated  during  the  Vietnam  War  as 
a  way  of  finding  out  how  the  enemy  was  obtaining  advanced  information  on  certain 
combat  operations  in  Southeast  Asia.10  OPSEC  is  a  countermeasures  program  for 
protecting  critical  information  (see  also  Army  Regulation  530-1,  Operations  Secu¬ 
rity;11  Joint  Doctrine  for  Operations  Security;12  Williams,  1999;  and  Hamby,  2002). 
OPSEC  involves  the  following  five  steps: 

1 .  Identify  the  critical  information  to  be  protected. 

2.  Analyze  the  threats. 

3.  Analyze  vulnerabilities. 

4.  Assess  risks. 

5.  Apply  countermeasures. 

The  five  OPSEC  steps  parallel  VAM  in  general,  with  the  added  explicit  representation 
of  threat  and  risk  assessments.  Nevertheless,  OPSEC  doctrine  typically  contains  little 
guidance  on  how  to  identify  vulnerabilities  or  select  countermeasures  to  address 
them.  Here  the  techniques  in  the  VAM  methodology  could  be  useful. 


10See  U.S.  Army  Communications  Electronics  Command  (1999). 
11U.S.  Department  of  the  Army  (1995). 

12Joint  Chiefs  of  Staff  (1997). 
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Operational  Risk  Management 

Operational  Risk  Management  (ORM)  is  another  military  process  for  managing  risks 
across  all  hazards  facing  the  military  (i.e.,  including  but  not  limited  to  information 
system  hazards).13  ORM  is  a  decisionmaking  process  designed  to  review  and  antici¬ 
pate  basic  aspects  of  hazards  and  reduce  risks  to  acceptable  levels.  ORM  grew  out  of 
ideas  originally  developed  to  improve  safety  in  the  development  of  weapons,  aircraft 
and  space  vehicles,  and  nuclear  power.  The  U.S.  Army  adapted  ORM  in  1991  to 
reduce  training  and  combat  losses.  ORM  involves  the  following  five  steps: 

1.  Identify  hazards. 

2.  Assess  hazards. 

3.  Make  risk  decisions. 

4.  Implement  controls. 

5.  Supervise. 

The  basic  concept  in  ORM  is  to  conduct  a  risk-reduction  review  and  provide  these 
five  general  steps  as  items  that  should  be  considered,  rather  than  providing  a 
detailed  methodology  for  all  types  of  hazards.  ORM  recommends  the  use  of  tech¬ 
niques,  such  as  brainstorming,  to  generate  ideas  and  affinity  diagrams  to  break  down 
an  operation  into  categories  (e.g.,  enemy,  troops,  terrain,  time)  in  order  to  focus  the 
analysis  on  one  area  at  a  time.14 

As  with  OPSEC,  the  five  ORM  steps  parallel  VAM  in  general,  with  the  added  explicit 
representation  of  making  risk  decisions.  ORM  doctrine  also  contains  little  guidance 
on  how  to  identify  hazards  (vulnerabilities)  or  select  controls  (countermeasures)  to 
address  them.  Here  also  the  techniques  in  the  VAM  methodology  could  be  useful. 

Integrated  Vulnerability  Assessments 

Navy  Integrated  Vulnerability  Assessments  (IVAs)  involve  checklist  reviews  of  sys¬ 
tems  in  order  to  list  the  top  vulnerabilities  a  command  is  concerned  with  and  is  fol¬ 
lowed  by  brainstorming  security  mitigations  that  can  be  implemented  in  response. 
An  additional  methodology,  CARVER  (Criticality,  Accessibility,  Recuperability,  Vul¬ 
nerability,  Effect,  and  Recognizability),  is  mentioned  as  a  means  for  prioritizing  vul¬ 
nerabilities.  CARVER  uses  very  rough  rating  categories  that  can  in  themselves  be 
interesting.  However,  the  numeric  ratings,  and  especially  the  technique  of  summing 
these  ratings  together  into  a  single  numeric  rating,  are  flawed.  CARVER’S  simple 
numeric  scoring  scheme  does  not  accurately  preserve  important  distinctions  among 
categories.  Also,  there  is  little  reason  to  believe  that  combining  ratings  of  very  differ¬ 
ent  aspects  of  the  problem  (e.g.,  time,  importance,  physical  measures,  effects)  will 
yield  a  meaningful  numeric  score. 


13See,  for  example,  U.S.  Department  of  the  Air  Force  (2000a, b,c);  U.S.  Naval  Safety  Center  (1997);  and  U.S. 
Naval  Safety  Center,  “Operational  Risk  Management”  (webpage). 

14See,  for  example,  the  tutorial  by  the  U.S.  Naval  Safety  Center  (n.d.). 
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Despite  the  problems  with  CARVER,  the  following  basic  steps  of  an  IVA  remain  valid: 

1 .  Identify  vulnerabilities. 

2.  Prioritize  vulnerabilities. 

3.  Brainstorm  countermeasures. 

4.  Assess  risks. 

As  with  OPSEC  and  ORM,  basic  steps  in  CARVER  parallel  VAM  in  general,  with  the 
added  explicit  representation  of  risk  assessments.  CARVER  contains  little  guidance 
on  how  to  identify  vulnerabilities,  and  “brainstorming”  countermeasures  are  of  little 
help.  Thus,  the  techniques  in  the  VAM  methodology  for  identifying  vulnerabilities 
and  exploring  countermeasures  are  relevant  to  CARVER  studies. 

The  VAM  Methodology  Techniques  Fill  Critical  Needs  in  Other 
Methodologies 

While  many  of  these  methodologies  (including  VAM)  use  similar  philosophies  and 
guidelines  (i.e.,  reviewing  critical  functions,  identifying  vulnerabilities,  choosing 
mitigation  techniques,  implementing  techniques,  and  testing  for  robustness  under 
threats),  the  VAM  methodology  complements  the  others  in  that  it  provides  an 
explicit  mechanism  to  help  an  evaluator  understand  what  leads  to  vulnerabilities, 
what  security  techniques  apply  to  the  vulnerabilities  identified,  and  what  potential 
problems  may  arise  from  the  security  techniques  themselves.  Given  the  good  efforts 
by  these  organizations  to  institutionalize  security  reviews,  it  may  make  sense  for  the 
organizations  to  adopt  the  methods  in  steps  3  and  4  of  the  VAM  methodology  as  a 
way  to  improve  their  own  utility  and  provide  detailed  guidance  to  the  evaluators  in 
their  communities  (see  Figure  3.7). 


•  VAM  Methodology 

1 .  Identify  essential  information  functions 

2.  Identify  essential  information  systems 


•  ORM  (Operational  Risk 
Management) 
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4.  Identify  pertinent  security  techniques 
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5.  Apply  techniques 
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•  OPSEC  (Operations  Security) 

1 .  Identify  critical  information 

2.  Analyze  threats 

^  3.  Analyze  vulnerabilities 


Figure  3.7 — The  Core  of  the  VAM  Methodology  Can  Be  Used  in  Other 
Traditional  Methodologies 


Chapter  Four 

VULNERABILITY  ATTRIBUTES  OF  SYSTEM  OBJECTS 


Here  we  present  the  lists  and  descriptions  of  vulnerability  attributes,  how  they  can  be 
mapped  in  a  user  form  to  system  objects,  and  how  some  common  security  problems 
exploit  these  attributes.  Thus,  this  chapter  provides  details  on  step  3  of  the  VAM 
methodology. 

VULNERABILITY  ATTRIBUTE  CATEGORIES 

Figure  4.1  lists  the  general  properties  of  objects  that  can  lead  to  vulnerabilities.  Vul¬ 
nerability  attributes  include  those  related  to  the  design  and  architecture  of  the  sys¬ 
tem,  the  behavior  and  actions  taken  by  the  system,  and  general  attributes  that  cut 
across  both  structure  and  behavior.  These  somewhat  conceptual  attributes  apply 
generally  to  many  types  of  systems  and  at  various  levels  within  the  systems. 

Table  4.1  maps  the  attributes  that  can  lead  to  vulnerabilities  to  all  four  types  of  sys¬ 
tem  objects:  physical,  cyber,  human/social,  and  supporting  infrastructure.  Attributes 
are  grouped  according  to  whether  they  arise  from  the  design  or  architecture  of  the 
system  object,  from  the  behavior  of  the  system  object,  or  more  generally  from  both. 

A  VULNERABILITY  CHECKLIST  AND  EXAMPLE 

Table  4.1  can  be  used  as  a  checklist  or  form  to  be  completed  by  the  evaluator  when 
examining  the  information  system.  In  this  way,  he  or  she  can  review  the  entire  list  of 
vulnerability  attributes  across  all  the  object  types  for  the  system  (or  subsystem)  being 
studied.  Table  4.2  shows  the  checklist  completed  with  the  following  common  secu¬ 
rity  concerns. 

Insider  Threat 

Vulnerability  Attribute:  Malevolence. 

Type  of  Target:  Human/ social. 

Description:  It  is  widely  believed  that  the  “insider  threat’’  (malevolent  behavior  by  a 
trusted  person  with  approved  access  to  critical  information  systems)  is  the  greatest 
threat  to  the  security  of  information  systems.  The  “insider”  might  be  someone  with  a 
grudge,  or  co-opted  by  an  enemy  through  blackmail,  bribes,  or  the  like. 
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and 
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Figure  4.1 — Properties  Leading  to  Vulnerabilities 


Inability  to  Handle  Distributed  Denial-of-Service  Attacks 
Vulnerability  Attribute:  Behavioral  sensitivity/fragility. 

Type  of  Target:  Cyber. 

Description:  One  of  the  most  difficult  kinds  of  cyber  attacks  to  handle  is  the  dis¬ 
tributed  denial-of-service  (DDoS)  attack,  wherein  hundreds  or  thousands  of  different 
computers  bombard  a  specific  network  node  or  component  with  packets  or  requests 
for  service — usually  ones  with  erroneous  information  that  require  additional  time  for 
processing.  Information  networks  must  be  specially  configured  and  designed  if  they 
are  to  thwart  (to  the  extent  possible)  this  kind  of  attack  that  depends  on  behavioral 
characteristics  and  sensitivities  of  the  network(s). 

IP  Spoofing 

Vulnerability  Attribute:  Gullibility/  deceivability/  naivete. 

Type  of  Target:  Cyber. 

Description:  To  “spoof”  an  Internet  Protocol  (IP)  address,  within  a  packet  or  mes¬ 
sage,  means  to  substitute  an  erroneous  address  in  the  place  where  a  valid  one  should 
appear.  By  this  means,  it  becomes  difficult  to  ascertain  the  true  sender  of  an  infor¬ 
mation  packet  or  session,  and  therefore  to  permit  various  forms  of  attack  that  dis¬ 
guise  their  source. 
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Table  4.1 

Matrix  of  Vulnerability  Attributes  and  System  Object  Types 


RAUDMR1601-table4. 1 


Object  of  Vulnerability 
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Cyber 

Human/Social 
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Hardware  (data  storage, 
input/output,  clients, 
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communications,  locality 
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Staff,  command, 
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Table  4.2 

Example  Completed  Vulnerability  Checklist 


RAUDMR1601-table4.2 


Object  of  Vulnerability 

Physical 

Cyber 

Human/Social 

Enabling  Infrastructure 

Attributes 

Hardware  (data  storage, 
input/output,  clients, 
servers),  network  and 
communications,  locality 

Software,  data, 
information,  knowledge 

Staff,  command, 
management,  policies, 
procedures,  training, 
authentication 

Ship,  building,  power, 
water,  air,  environment 

Design/Architecture 

Singularity 

Uniqueness 

Centrality 

Centralized  Network 
Operations  Centers 
(NOCs) 

Homogeneity 

Standardized  software 

Separability 

Logic/ 

implementation 
errors;  fallibility 

Weaknesses  in  router  or 
desktop  applications 
software 

Design  sensitivity/ 

fragility/limits/ 

finiteness 

Electronic  environmental 
tolerances 

Un  recoverability 

Behavior 

Behavioral  sensitivity 
fragility 

Inability  to  handle 
(DoS)  attacks 

Malevolence 

Insider  threat 

Rigidity 

Malleability 

Gullibility/ 

deceivability/naivete 

IP  spoofing 

Complacency 

Corruptibility/ 

controllability 

General 

Accessible/ 

detectable/ 

identifiable/ 

transparent/ 

interceptable 

Hard  to  manage  or 
control 

Self-unawareness 
and  unpredictability 

Inability  to  detect  changes 
to  IP  net,  making  IP 
masking  possible 

Predictability 

Common  commercial 
hardware  is  well  known 
and  predictable 

Common  commercial 
software  is  well  known 
and  predictable 
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Inability  to  Detect  Changes  to  IP  Net,  Making  IP  Masking  Possible 
Vulnerability  Attribute:  Self-unawareness  and  unpredictability. 

Type  of  Target:  Cyber. 

Description:  If  an  IP  network  does  not  have  active  monitoring  programs  and  tools  to 
allow  personnel  to  ascertain  whether  or  not  a  new  host  (IP  address)  has  been 
inserted,  or  removed,  from  the  net,  then  it  could  be  possible  for  someone  to  insert  an 
unauthorized  laptop  or  another  device  onto  a  network  connection  and  download 
information  into  that  device.  This  danger  is  especially  prevalent  for  wireless  net¬ 
works,  where  the  “connection”  can  be  from  a  location  away  from  visible  network 
ports  or  even  outside  the  organization’s  building.  This  is  a  lack  of  “self-awareness”  of 
the  network  configuration,  and  changes  to  it,  during  its  operation. 

Centralized  Network  Operations  Centers 
Vulnerability  Attribute:  Centrality. 

Type  of  Target:  Physical. 

Description:  Network  operations  centers  can  contain  many  vital  physical  compo¬ 
nents  (e.g.,  key  equipment  and  backups)  in  one  central  location.  As  such,  a  physical 
attack  could  disable  not  only  primary,  but  also  backup,  routers  and  key  communica¬ 
tions  equipment. 

Common  Commercial  Software  and  Hardware  Are  Well  Known  and 
Predictable 

Vulnerability  Attribute:  Predictability. 

Type  of  Target:  Physical  and  Cyber. 

Description:  The  personal  computers,  workstations,  routers,  servers,  and  other  com¬ 
ponents  of  critical  information  systems  are  often  based  heavily  on  commercial  prod¬ 
ucts,  such  as  Cisco  router  software,  Windows  NT,  and  Microsoft  Outlook,  Word, 
Excel,  PowerPoint,  etc.  As  such,  the  vulnerabilities,  organization,  and,  in  some  cases, 
source  code  of  these  types  of  programs  are  widely  known.  The  programs  are  thus 
highly  predictable  in  that  other  copies  of  them  can  be  tested  to  find  situations  (e.g., 
exceeding  the  capacity  of  a  database)  in  which  their  performance  fails. 

Standardized  Software 
Vulnerability  Attribute:  Homogeneity. 

Type  of  Target:  Cyber. 
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Description:  The  heavy  use  of  standardized  software  for  routers  (e.g.,  Cisco  operating 
system),  servers  (e.g.,  Windows  NT),  and  PCs/workstations  (e.g.,  Windows  NT  or 
Macintosh  OS)  creates  a  very  homogeneous  information  and  communication  sys¬ 
tem.  Any  flaw  in  one  of  these  designs  can  be  replicated  widely  within  the  information 
system  and  therefore  can  provide  a  common  vulnerability  across  the  system. 

Weaknesses  in  Router  or  Desktop  Applications  Software 
Vulnerability  Attribute:  Logic/implementation  errors;  fallibility. 

Type  of  Target:  Cyber. 

Description:  There  may  be  fundamental  design  or  implementation  flaws  in  standard 
software  used  in  operating  systems  (workstation  and  router)  and  desktop  applica¬ 
tions.  These  flaws,  if  they  become  known  to  an  attacker,  could  provide  unauthorized 
access  or  destruction. 

Electronic  Environmental  Tolerances 

Vulnerability  Attribute:  Design  sensitivity/fragility/limits  /finiteness. 

Type  of  Target:  Physical. 

Description:  Various  commercial  electronic  equipment  vital  to  network  communi¬ 
cations  and  computing  are  often  not  hardened  for  environmental  influences  (e.g., 
temperature,  smoke,  humidity)  or  extreme  attack  means  (e.g.,  electromagnetic 
pulses  [EMPs]). 

DESCRIPTION  OF  VULNERABILITY  ATTRIBUTES 

Here  are  the  attributes  that  lead  to  vulnerabilities,  with  short  descriptions  for  each. 
Additional  examples  and  discussions  of  these  attributes  can  be  found  in  Anderson  et 
al.  (1999). 

Note  that  some  vulnerabilities  display  more  than  one  of  these  attributes  at  a  time, 
often  leading  to  a  chain  of  attack  or  a  series  of  faults  to  meet  the  ultimate  goal  of  an 
attack  or  resulting  in  a  non-intentional  system  failure. 

Design  and  Architecture  Attributes 

The  attributes  of  the  design  and  architecture  of  a  system  object  provide  structural 
characteristics  that  can  lead  to  vulnerabilities.  These  attributes  are  grouped  in  the 
following  broad  categories: 

Singularity.  Singularity  is  an  important,  broad  category  that  can  provide  important 
targets  or  single  points-of-failure  with  profound  effects.  Singularity  encompasses 
uniqueness,  centrality,  and  homogeneity. 
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•  Uniqueness.  Uniqueness  is  singularity  in  availability  where  an  object  may  be  the 
only  one  of  its  kind.  Besides  being  difficult  to  replace,  unique  objects  may  be  less 
likely  to  have  been  thoroughly  tested  and  perfected.  Examples  include  one-of-a- 
kind  items  no  longer  being  manufactured  or  people  with  special  knowledge  or 
expertise  that  cannot  be  readily  transferred  to  others. 

•  Centrality.  Centrality  is  singularity  in  location  where  the  failure  points  are  col¬ 
lected  in  a  single  place.  Examples  include  decisions,  data,  or  control  passing 
through  a  central  node  or  process. 

•  Homogeneity.  Homogeneity  is  singularity  in  type  where,  through  replication, 
multiple,  identical  objects  share  common  flaws  or  weaknesses.  Using  a  single 
type  of  object  provides  a  common  target  that,  if  compromised,  affects  all  the 
system  functions  it  supports. 

Grouping  these  three  types  under  “singularity”  recognizes  that  these  attributes  all 
exhibit  singularity  but  in  different  ways.  For  example,  a  single  point  of  failure  may  be 
due  to  the  difficulty  in  replacing  it  (uniqueness),  the  collection  of  critical  nodes  in  a 
single  location  (centrality),  or  the  widespread  compromise  of  a  system  once  the 
weaknesses  in  a  common  object  are  discovered. 

Separability.  Separability  implies  that  the  object  could  easily  be  isolated  from  the 
rest  of  the  system.  Separable  objects  are  subject  to  divide-and-conquer  attacks, 
where  protection  information  (e.g.,  security  updates),  attack  reinforcements,  or 
postattack  repairs  can  be  blocked  or  seriously  delayed.  Examples  include  networks 
that  can  be  bifurcated  into  two  noncommunicating  subnets. 

Logic  and  Implementation  Errors;  Fallibility.  Errors  in  the  logic,  implementation,  or 
structures  of  the  system  object  can  directly  provide  access,  an  exploitable  target,  or 
non-attribution  to  an  attacker.  These  errors  can  affect  system  reliability,  availability, 
understandability,  maintainability,  and  other  important  aspects.  Errors  and  fallibili¬ 
ties  can  arise  from  failures  to  meet  system  requirements  or,  in  more  fundamental 
flaws,  in  the  requirements  themselves.  Errors  and  fallibilities  can  also  arise  from 
insufficient  validation,  verification,  and  accreditation  (W&A);  insufficient  test  and 
evaluation;  lack  of  rigorous  systems  engineering;  or  from  technical  or  scientific  defi¬ 
ciencies  or  immaturities. 

Design  Sensitivity,  Fragility,  Limits,  or  Finiteness.  Rather  than  flaws  or  errors,  these 
attributes  arise  from  the  natural  limitations  of  all  systems.  No  real-world  system  can 
be  designed  with  unlimited  capacity  and  capability.  Examples  include  vulnerability 
to  environmental  exposures,  variations  in  inputs,  abnormal  use,  and  overloading. 
Appropriate  error  handling  could  mitigate  these  limitations,  but  vulnerabilities  ensue 
when  proper  error  handling  is  not  implemented. 

Unrecoverability.  Objects  that  have  irreplaceable  components  or  information,  as 
well  as  those  that  require  an  inordinate  time  (relative  to  functional  requirements)  or 
effort  (relative  to  available  resource)  to  recover  from  failure  states  or  be  replaced,  can 
provide  a  tempting  target  if  they  provide  critical  capabilities.  Examples  include  sys¬ 
tems  with  long  reboot  times  relative  to  operational  response  times  and  systems  that 
lose  critical  state  information. 
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Behavioral  Attributes 

In  addition  to  its  structural  features,  an  object’s  behavior  can  exhibit  characteristics 
that  are  exploitable.  Here  are  the  major  behavioral  attributes  that  can  lead  to  such 
vulnerabilities. 

Behavioral  Sensitivity  or  Fragility.  These  attributes  involve  how  the  object  behaves 
or  reacts,  and  how  robust  the  object  is  to  changes  in  input  and  environmental  condi¬ 
tions.  Examples  include  behavioral,  functional,  and  operational  sensitivity  to  actions, 
configurations,  settings,  inputs,  etc. 

Malevolence.  Systems  or  people  that  actively  work  against  the  broader  information 
system  and  its  security  (e.g.,  insider  threats)  can  directly  damage  the  function  of  the 
system  or  be  exploited  by  external  entities  to  increase  their  malevolence. 

Rigidity.  Rigidity  or  lack  of  adaptiveness  involves  configurations,  behaviors,  or 
responses  not  easily  changed  in  response  to  an  attack.  Also,  a  lack  of  preplanned 
procedures  (e.g.,  contingency  plans  and  MOUs1)  can  limit  the  available  actions  of  an 
object,  making  it  more  likely  to  fail  or  greatly  slowing  its  function. 

Malleability.  Objects  that  can  be  easily  modified,  manipulated,  changed,  inserted,  or 
deleted  pose  potential  weaknesses  to  both  internal  and  external  threats. 

Gullibility,  Deceivability,  or  Naivete.  Objects  with  these  attributes  are  easy  to  fool. 
Examples  include  recruitable  insiders,  the  inability  to  handle  uncertain  data,  insuffi¬ 
cient  trust  models,  the  inability  to  recognize  one’s  own  biases  and  when  they  can 
lead  to  duping,  repudiation  and  lack  of  authentication,  and  the  ability  to  be  duped 
into  an  inappropriate  response  (i.e.,  being  manipulated  into  a  security  state  or  pos¬ 
ture  that  is  too  high  or  low  given  the  real  threat,  resulting  respectively  in  less- effective 
operations  or  insufficient  protections) . 

Complacency.  A  lack  of  security  diligence  (e.g.,  poor  administrative  procedures  or 
insufficient  screening)  or  responsiveness  implies  a  weak  security  posture  and  an  in¬ 
ability  to  respond  to  threats. 

Corruptibility  or  Controllability.  These  attributes  imply  a  weakness  that  can  be 
exploited  to  make  an  object  act  in  error  or  become  a  malevolent  agent.  Examples 
include  people  that  can  be  manipulated  or  corrupted  into  insider  threats;  inputs, 
outputs,  and  memory  that  can  be  changed;  and  systems  or  organizations  that  can  be 
controlled  without  the  knowledge  of  their  individual  components. 

General  Attributes 

These  attributes  cut  across  both  the  structure  and  behavior  of  the  object. 


1  Memoranda  of  understanding  (MOUs). 


Vulnerability  Attributes  of  System  Objects  33 


Accessible,  Detectable,  Identifiable,  Transparent,  or  Interceptable.  These  exposures 
apply  to  architecture,  behavior,  adaptations,  data,  etc.,  and  form  the  basis  of  a  critical 
step  in  an  attack.  Without  access,  for  example,  one  cannot  attack  a  system. 

Hard  to  Manage  or  Control.  Difficulty  in  configuring,  controlling,  or  maintaining  an 
object  or  system  can  make  it  difficult  to  find,  fix,  or  prevent  flaws;  establish  proper 
security  protections  and  responses;  and  bound  the  behavior  of  the  system  or  its 
components. 

Self-Unawareness  and  Unpredictability.  Just  as  knowledge  is  critical  to  an  attacker, 
self-awareness  is  critical  to  the  defender  to  know  who  and  what  constitutes  the  sys¬ 
tem,  how  it  interconnects  and  interoperates,  and  how  and  when  the  system  is  being 
compromised.  Likewise,  the  inability  to  predict  how  your  system  is  configured  or  will 
behave  limits  the  knowledge  available  to  respond  to  problems  and  attacks.  Self¬ 
unawareness  can  also  occur  within  the  system  itself  (e.g.,  an  inability  to  detect 
“alien”  code  within  its  own  software). 

Predictability.  Predictability  of  the  object’s  design,  architecture,  or  behavior  by  an 
adversary  allows  the  adversary  to  plan  and  construct  attacks  from  afar,  to  understand 
how  the  object  will  respond,  and  to  manipulate  the  object  into  desired  states  or  fail¬ 
ure  modes. 

HOW  VULNERABILITY  PROPERTIES  COMBINE  IN  COMMON  THREATS 

The  following  examples  demonstrate  how  vulnerability  properties  can  be  combined 
to  provide  significant  information  security  problems. 

First,  consider  DDoS  attacks  that  take  down  an  Internet  service  by  flooding  it  with 
seemingly  legitimate  service  requests  from  multiple,  distributed  sources.  Figure  4.2 
shows  that  DDoS  exploits  design  limits  in  traffic  capacity,  rigidity  in  rerouting  and 
blocking  incoming  traffic,  and  difficulty  in  managing  a  system  in  which  control  is 
distributed  among  multiple  cooperating  entities  with  no  single  management  author¬ 
ity  that  regulates  traffic. 

Second,  consider  penetrations  of  firewalls  set  up  to  block  illegitimate,  untrusted,  or 
unauthorized  accesses  and  requests.  Figure  4.3  shows  that  firewall  penetrations  can 
take  advantage  of  homogeneity  in  the  global  sense  that  market  dominance  and  stan¬ 
dardization  in  firewalls,  routers,  and  other  network  components  make  it  easier  to 
exploit  known  vulnerabilities  in  these  components.  Also,  when  an  attacker  deter¬ 
mines  how  to  penetrate  an  organization  with  common  firewalls,  the  attacker  can 
penetrate  systems  across  the  entire  organization.  Firewall  penetrations  also  depend 
on  accessibility  vulnerabilities  (e.g.,  presence  on  open  networks),  difficulty  in  firewall 
and  network  management  (e.g.,  difficulties  in  configuring  the  firewalls  initially  or  in 
reconfiguring  the  firewall  to  block  known  attackers),  and  self-unawareness  (i.e., 
when  system  operators  do  not  know  if  their  systems  have  been  compromised,  who 
the  penetrators  are,  what  areas  have  been  compromised,  or  even  how  their  system  is 
configured  so  they  can  adjust  the  configuration  to  block  further  penetrations). 
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Figure  4.2 — Vulnerabilities  Enabling  Distributed  Denial  of  Service 
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Figure  4.3 — Vulnerabilities  Enabling  Firewall  Penetrations 
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Third,  consider  network  mapping  (e.g.,  using  network  scanning  and  probing  tools) 
by  an  adversary  to  collect  knowledge  about  the  target  system  for  future  exploitation. 
Figure  4.4  shows  that  network  mapping  can  take  advantage  of  a  large  number  of  vul¬ 
nerabilities.  Centrality  provides  “one-stop  shopping”  for  information,  making  it  eas¬ 
ier  to  find  all  the  systems  of  interest.  Homogeneity  implies  that  the  attacker  can 
apply  his  or  her  knowledge  across  a  large  number  of  systems  or  even  across  the 
whole  organization.  Rigidity  keeps  the  network  configuration  very  consistent,  pre¬ 
serving  the  validity  of  whatever  knowledge  the  adversary  gathers.  Gullibility  allows 
the  network  mapper  to  employ  deceptions  to  gather  information  (both  from  cyber 
probes  and  from  social  engineering).  Access  to  the  system  facilitates  probes,  open- 
source  intelligence  gathering,  and  social  engineering.  Difficulty  in  managing  a  net¬ 
work,  along  with  unawareness,  reduces  the  ability  of  the  defender  to  keep  out  net¬ 
work  probes  and  recognize  when  one’s  system  is  the  target  of  intelligence  gathering. 
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Figure  4.4 — Vulnerabilities  Enabling  Network  Mapping 
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Finally,  consider  Trojan  horse  attacks  on  a  computer  system.  Figure  4.5  shows  that 
Trojan  horses  exploit  not  only  gullibility  (the  traditional  concept  from  the  story  of  the 
Trojan  horse)  but  other  vulnerabilities  as  well.  A  Trojan  horse  can  enter  a  system 
when  gullible  software  trusts  too  much  of  the  data  submitted  to  it,  gullible  users 
open  email  attachments  that  appear  suspicious  to  the  trained  eye,  or  gullible  users 
load  software  from  uncertified  sites.  Homogeneity  makes  it  easier  to  focus  an  attack 
on  a  single  type  of  target  and  compromise  systems  across  the  organization.  Control¬ 
lability  allows  the  Trojan  to  take  over  computers  and  use  them  for  other  exploits  and 
attacks.  Self-unawareness  prevents  the  user  from  detecting  not  only  the  initial  Trojan 
horse  but  also  indicators  that  the  computer  has  been  compromised  and  is  being 
controlled  for  other  purposes.  Difficulty  in  managing  one’s  system  implies  that  it 
may  be  hard  to  reassert  control  and  delete  the  Trojan  once  it  has  infected  the  system. 
Finally,  accessibility  allows  the  Trojan  horse  to  present  itself  to  the  system  or  user  in 
the  first  place. 
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Figure  4.5 — Vulnerabilities  Enabling  Trojan  Horse  Attacks 


Chapter  Five 

DIRECT  AND  INDIRECT  SECURITY  TECHNIQUES 


This  chapter  provides  an  in-depth  description  of  information  system  security  tech¬ 
niques  that  help  to  mitigate  vulnerabilities.  Techniques  are  grouped  according  to  the 
fundamental  concepts  they  employ.  These  security  technique  categories  are  what  the 
matrix  and  filters  in  step  4  recommend  based  on  the  types  of  vulnerability  attributes, 
user  role,  and  attack/ failure  stage  in  question. 

The  chapter  ends  by  describing  how  some  well-known  security  approaches  rely  on 
one  or  more  of  these  fundamental  categories. 

SECURITY  TECHNIQUE  CATEGORIES  AND  EXAMPLES 

The  security  field  has  identified  and  developed  a  large  number  of  security  tech¬ 
niques,  employing  various  strategies  to  mitigate  vulnerabilities.  Some  techniques 
make  system  objects  resilient  to  attacks  or  failures.  Other  techniques  enable  active 
identification  and  response  to  attacks  or  failures.  Additional  techniques  block  critical 
attack  components  or  failure  causes  from  reaching  the  object.  Further  techniques 
deter  attackers  from  even  trying  an  attack  in  the  first  place.  Figure  5.1  lists  the  major 
techniques  of  relevance  to  information  system  objects,  grouped  by  whether  they 
improve  the  resilience  or  robustness  of  the  object  from  attack  or  failure,  whether  they 
improve  knowledge  and  awareness  of  an  attack  or  failure,  whether  they  deny  knowl¬ 
edge  and  awareness  to  an  attacker,  or  whether  they  deter  and  punish  attackers.  Many 
of  these  techniques  overlap  and  complement  each  other,  but  the  categories  provide 
important  distinctions  and  properties  in  and  of  themselves. 

Resilience  and  Robustness 

The  first  general  category  of  security  techniques  involves  making  the  system  more 
resilient  and  robust  to  attack. 

Heterogeneity.  Heterogeneity  includes  component  types,  operating  ranges,  manu¬ 
facturers,  expertise,  background,  etc.;  randomized  compilation  creating  diversity; 
multimedia;  and  parallel  heterogeneity  (e.g.,  parallel  email  programs  with  synchro¬ 
nization)  . 
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Redundancy.  Redundancy  includes  alternative  systems  and/or  methods  to  accom¬ 
plish  what  a  system  does.  The  evaluator  should  also  consider  path  diversity,  bi-  or  n- 
connectedness,  mirroring  of  databases,  excess  capacity,  and  stockpiling. 

Centralization.  Centralization  includes  the  following:  central  collection  of  informa¬ 
tion,  reporting,  alerting,  repairs,  and  updates  to  gain  a  common  operating  picture  of 
physical  systems,  quality  control,  cost  savings,  etc.;  and  centralized  location  of  man¬ 
agement  (or  virtual  centralization  via  communications)  to  provide  consistency, 
coordination,  etc. 

Decentralization.  The  evaluator  should  consider  decentralized  control  points,  rout¬ 
ing,  backups,  configuration  data,  repair  points,  staff;  distributed,  mobile  processing; 
rotated  responsibilities;  and  redundant  information  at  different  places. 

W&A,  Software  and  Hardware  Engineering,  Evaluations,  or  Testing.  The  broad  area 
of  rigorous  design  and  engineering  of  information  system  components  includes 
quality  information  system  production;  procedural  certification  (e.g.,  the  Capability 
Maturity  Model1);  personnel  and  system  testing,  training,  licensing,  and  certification; 
security  procedures,  checklists,  and  checks;  security  modeling,  evaluation,  and  test- 


1See  www.sei.cmu.edu/cmm/. 
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ing;  red  teaming  (e.g.,  general  security,  intrusions,  clearances,  access);  and  exercises 
(real,  simulated,  tabletop) . 

Control  of  Exposure,  Access,  and  Output.  Controlling  the  boundary  of  the  informa¬ 
tion  system  is  the  most  common  area  of  attention  in  information  security.  Tech¬ 
niques  include  cryptography,  encryption,  and  public  key  infrastructures  (PKIs); 
passwords,  synchronized  pseudorandom  number  generators;  biometrics;  smart 
cards;  firewalls,  filters,  behavior  limits;  guards  (ingress  and  egress);  one-way  gate¬ 
ways;  backdoor  elimination;  uncopyable  media  or  information;  self-protecting  pack¬ 
aging;  air-gapped  and  off-line  systems  and  backups;  classification  and  compartmen- 
talization  (insider  access  based  on  privileges,  clearances,  roles,  capability,  or 
behavior);  data,  code,  and  process  segmentation;  wrapping  trusted  components 
(protect);  wrapping,  quarantining,  or  segregating  untrusted  components  (control 
behavior  and  contain  any  damage);  I/O  checking  (error  checking,  tight  type  and 
range  checking,  etc.);  physical  security  measures  (e.g.,  electromagnetic  shielding, 
fences,  barriers,  security  guards,  proper  distance  from  barriers,  locks,  positive  or 
negative  air  pressure,  etc.);  using  meta-data  in  support  of  classification, 
identification,  and  reasoning  functions;  nondisclosure  during  transit  (encryption); 
and  integrity  verification. 

Trust  Learning  and  Enforcement  Systems.  Trust  should  be  the  basis  of  permitting 
access,  acting  on  data,  and  using  system  components  from  others  (e.g.,  software  and 
files).  Specific  approaches  include  recording  lessons  learned,  using  consensus  tech¬ 
niques,  administering  trust  and  experience  surveys,  collecting  shared  experience, 
and  using  trusted  third  parties  to  validate  information  and  components. 

Non-Repudiation.  Techniques  that  prevent  repudiation  (and  its  earlier  stage  of  attri¬ 
bution)  include  proof  of  receipt  and  ownership;  authentication;  PKI;  and  recording 
all  accesses,  read/writes,  and  data  sources  (sign-in  and  sign-out  logs,  video  monitor, 
access  logs,  meta-data  structures,  etc.). 

Hardening.  Hardening  an  object  to  withstand  attacks  that  get  through  protections 
can  be  a  final,  yet  important,  stand.  Approaches  include  hardened  electronics;  error- 
correcting  codes  and  software;  robust  staff  and  procedures  (even  if  only  a  subset  of 
components  remains  to  provide  minimal  capability);  EMP,  environmental,  shock,  or 
surge-tolerant  equipment;  read-only  (write-protect)  data  storage,  configurations, 
network  tables,  etc.;  and  read-only  memory  (ROM). 

Fault,  Uncertainty,  Validity,  and  Quality  Tolerance  and  Graceful  Degradation.  Simi¬ 
lar  to  hardening,  tolerance  and  graceful  degradation  allows  the  object  to  tolerate 
faults,  uncertainty,  invalidity,  and  poor  quality  by  adjusting  behavior  and  perfor¬ 
mance  to  accommodate  the  problems  without  failing.  Techniques  include  separabil¬ 
ity  (to  allow  isolation  of  faulty  components);  tolerance  built  into  design  and 
approach;  minimal  ways  to  operate  degraded  equipment  (e.g.,  running  the  fans  in  an 
air  conditioner  when  the  cooling  components  fail;  running  central  processing  units 
[CPUs]  in  protected  modes  or  from  minimal  operating  systems  on  disks  with  mini¬ 
mal  extensions,  graphics,  etc.);  ability  to  handle  and  reason  with  uncertain,  partially 
reliable,  and  degraded  data;  accreditation  of  incoming  information  to  quantify  its 
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reliability  or  uncertainty;  validity  assessment;  source  verification;  providing  meta¬ 
data  for  data  quality;  and  uncertainty  reasoning  and  semantics. 

Static  Resource  Allocation.  Allocating  resources  in  predefined  ways  allows  time  for 
advanced  planning,  analyzing  the  consequences  of  changes,  and  looking  at  their 
implications  for  improving  the  system’s  security  posture.  Approaches  include 
restricting  nonessential  connections;  reducing  load  at  weak  points;  and  establishing 
and  implementing  guidelines  related  to  known  sensitivities  of  systems  (e.g.,  in  Win¬ 
dows  systems,  limiting  the  number  of  applications  open  at  the  same  time;  keeping 
the  use  of  unstable  applications  down  to  a  minimum,  especially  at  more  critical 
times  in  a  mission) . 

Dynamic  Resource  Allocation.  The  adaptive  partner  to  static  resource  allocation, 
dynamic  resource  allocation  utilizes  information  about  the  threat  or  problem  to 
adjust  resources  in  or  near  real  time,  often  involving  complex  and  changing 
responses.  Techniques  include  load  shedding  (demand,  throughput,  heat,  power, 
etc.);  prioritizing  clients  or  processes  (e.g.,  market-based,  managed  priorities);  cut¬ 
ting  off  offending  traffic  or  allocations  farther  upstream;  dynamic  administrative 
overhead  levels;  dynamic  network  reconfiguration  that  is  either  manual  or  auto¬ 
mated,  and  rule-driven,  case-based,  or  searched  (e.g.,  genetic  algorithms  or 
exploratory  modeling);2  keeping  the  use  of  unstable  hardware  or  software  down  to  a 
minimum  at  more  critical  times  in  a  mission;  and  dynamic  changes  to  provide  un¬ 
predictability  or  deception. 

General  Management.  Effective  management  can  improve  security  through  report¬ 
ing  systems,  structures,  and  procedures;  quality  control;  ensuring  that  default  set¬ 
tings  meet  security  needs;  peer  pressure;  information  dissemination  and  advertising; 
training;  security  campaigns  and  reminders;  warnings  and  threats;  policy  reminders 
and  motivators;  and  red  teaming  to  test  and  evaluate  procedures  and  compliance. 

Threat  Response  Structures  and  Plans.  Information  Conditions  (INFOCONs)  and 
other  preplanned  static  and  dynamic  protective  measures  employ  a  hierarchy  of 
increasing  information  system  protective  measures  to  be  taken  in  response  to  antici¬ 
pated  or  observed  attack  threat  levels.  Other  approaches  include  data  and  configura¬ 
tion  protection  and  backup;  establishment  of  backup  servers;  infrastructure  backup; 
security  plans  and  MOUs;  crisis  planning  and  management;  purging  and  filtering; 
adaptive  response  to  adaptive  attacks;  and  resource  reallocation. 

Rapid  Reconstitution  and  Recovery.  The  ability  to  reconstitute  or  recover  after  a 
failure  can  be  almost  as  effective  as  not  having  failed  in  the  first  place  if  the  response 
time  is  rapid  enough  relative  to  the  performance  needs  of  the  system.  Techniques 
include  data  protection  and  recovery;  warm  rebooting;  hot,  warm,  or  cold  backup 
servers;  reserved  and  alternate  channels  to  “reboot”;  having  reserve  staff  available 


2For  example,  networks  can  be  reconfigured  to  accommodate  new  loads,  bypass  unauthorized  traffic,  or 
facilitate  priority  traffic  based  on  available  network  management  information.  New  configurations  can  be 
constructed  by  employing  heuristic  rules,  searching  through  prior  cases,  or  searching  over  the  space  of 
simulated  performance  models  (e.g.,  using  exploratory  modeling  or  genetic  algorithms)  to  find  a  good  re¬ 
configuration  for  the  current  condition. 
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(either  directly  or  through  MOUs  with  nearby  organizations);  giving  each  network 
node  a  “genome”  (predefined  instruction  set)  for  rebooting;  infrastructure  backup 
and  recovery  approaches;  threat  response  plans  (e.g.,  security  plans,  MOUs  for 
prearranged  coordination,  or  crisis  planning  and  management);  dynamic  resource 
allocation  (e.g.,  purging  and  filtering);  adaptive  response  to  adaptive  attacks;  manual 
operation  and  recovery  plans;  locally  available  replacement  parts  (possibly  in  differ¬ 
ent  areas  to  provide  a  decentralized  target);  rapid  replacement  plans;  local  repair 
capabilities;  and  examining  what  hardware,  software,  and  data  are  the  hardest  to  re¬ 
generate  (and  thus  need  to  be  preserved  or  made  redundant) . 

Adaptability  and  Learning.  Adversaries  continually  learn  about  targets  and  adapt  to 
changing  defenses.  A  defender,  therefore,  must  adapt  to  these  changing  threats  or 
run  the  risk  of  being  outpaced  by  a  creative  adversary  that  can  simply  bypass  the 
defender’s  “Maginot  Line.”3  Techniques  include  building  adaptive  responses  to  un¬ 
known  or  adaptive  attacks;  extracting  lessons  learned  and  creating  best  security 
practices  databases  (a  gross  “immunological  system”  from  one  perspective); 
leveraging  centralization  to  improve  dissemination  of  lessons  learned  about  attacks; 
mining  attack  data  to  learn  what  the  adversary  is  doing,  develop  protective  actions, 
and  develop  countermeasures;  ensuring  sufficient  monitoring  and  tracking  to  inform 
learning;  developing  available  (rapid)  training  materials  and  critical  data  materials, 
especially  on  the  critical  operations  and  procedures  for  rapid  use  by  secondary  staff; 
and  establishing  dynamic  INFOCONs  and  other  threat  response  structures  and 
plans. 

Immunological  Defense  Systems.  Borrowing  from  biology,  an  “immunological”  sys¬ 
tem  incorporates  threat  recognition,  mitigation  development,  implementation,  and 
dissemination  across  the  system  and  organization.  Techniques  include  automatic 
(preferred)  or  manual  systems  to  detect  threats,  spread  warnings,  install  updates  or 
patches,  and  enact  security  measures;  automatic  commercial  off-the-shelf  (COTS) 
patch  and  profile  data  updates;  memory,  adaptation,  and  communication  (requires  a 
reporting  structure);  sharing  information  globally  on  attacks  to  piece  together  what  is 
happening  and  how  to  respond;  and  applying  concepts  to  develop  adaptive  and 
shared  INFOCON  procedures. 

Vaccination.  Another  concept  inspired  by  biology  involves  the  deliberate  attack 
(“infection”)  to  train,  recognize,  sensitize,  and  prepare  for  future  attacks  (with  or 
without  a  formal  “immunological  system”).  Red  teaming  to  sensitize  the  system  is 
one  such  approach. 


3The  Maginot  Line  was  a  French  network  of  defensive  weapon  emplacements  and  supporting  tunnels 
designed  to  thwart  potential  physical  attacks  along  the  German  boarder  after  World  War  I.  The  concept 
proved  obsolete  in  World  War  II  because  of  Germany’s  ability  to  rapidly  end-run  the  line  and  attack  from 
an  unprotected  angle. 
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Intelligence,  Surveillance,  Reconnaissance,  and  Self-Awareness 

The  second  general  category  of  security  techniques  involves  collecting  information 
about  the  threat  and  one’s  own  system — in  a  sense,  the  “intelligence  preparation  of 
the  battlefield.” 

Intelligence  Operations.  Intelligence  involves  the  full  range  of  information  gathering 
about  opponent  (goals,  thrusts,  methods,  capabilities,  etc.)  and  insider  operations. 
Ideally,  intelligence  covers  both  your  and  your  opponent’s  information  systems, 
since  they  constitute  the  “battlespace.”  Intelligence  not  only  can  detect  attacks  but 
can  also  gather  advanced  information  that  can  inform  protective  and  reactive  proce¬ 
dures. 

Self-Awareness,  Monitoring,  and  Assessments.  Knowing  about  your  own  system, 
being  able  to  monitor  it,  and  assessing  its  condition  is  often  a  critical  step  in  recog¬ 
nizing  and  then  mitigating  attacks  and  failures.  Techniques  include  self-monitoring 
(insider  or  outsider  threats);  security  audits  (e.g.,  the  VAM  methodology  and  IVA);  red 
teaming  to  gather  information;  network  monitoring  and  management  tools;  state 
and  performance  monitors;  documentation  of  your  system’s  configurations  and 
states;  static  modeling  and  understanding;  monitoring  and  recording  the  behavior  of 
applications  and  staff  (data  accessed  or  changed;  connections;  requests;  functions 
executed;  accesses  attempted;  etc.);  and  providing  capabilities  for  remote  monitoring 
from  centralized  locations  for  expert  consultations  and  monitoring. 

Deception  for  ISR.  Deception  can  be  a  useful  (and  unexpected)  technique  for  intelli¬ 
gence,  surveillance,  and  reconnaissance  (ISR),  since  by  its  very  nature  deception 
affects  information  flow.  Techniques  include  sting  and  intelligence  operations  using 
honeypots,  cutouts,  zombies,  decoys,  disguise,  structural  or  behavioral  mimicry,  etc.4 

Attack  Detection,  Recognition,  Damage  Assessment,  and  Forensics  (Self  and  Foe). 

Various  methods  are  available  to  detect,  recognize,  and  analyze  attacks,  as  well  as 
assess  the  scope  of  the  damage  from  these  attacks.  Techniques  include  real-time 
intrusion  detection;  learning  systems  (neural  nets,  self- organizing  maps,  etc.);  pat¬ 
tern  recognition  (case-based,  rule-based,  model-based  correlation,  etc.);  self-/non- 
self-discrimination;  internal  system  behavior  and  condition  monitoring;  deception 
for  detection  and  recognition  (e.g.,  spoofing,  canaries,  honeypots);  tamper  and  un¬ 
sealing  detection;  tracking  and  tracing;  special  monitoring  privileges;  corruption 
recognition;  use  of  design  specifications  to  bound  acceptable  hardware,  software, 
and  staff  behavior;  tamper-evident  barriers;  non-repudiation  mechanisms  (e.g., 
modification  records,  proofs  of  receipt  and  ownership,  authentication,  PKI);  access 
logs;  and  global  sharing  of  intelligence  data  to  aid  in  analysis. 


4See  Gerwehr  and  Glenn  (2000,  Chapter  3)  for  a  review  of  general  deception  techniques. 
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Counterintelligence;  Denial  of  ISR  and  Target  Acquisition 

The  third  general  category  of  security  techniques  involves  Cl,  as  well  as  denying  ISR 
and  target  acquisition  to  your  adversary — directly  affecting  your  adversary’s  ability  to 
gather  required  knowledge  about  your  system  for  an  attack. 

General  Cl.  Some  basic  Cl  techniques  for  information  systems  include  scans  for 
physical  monitors,  bugs,  etc.;  scans  for  software  Trojan  horses  and  monitors;  security 
checks;  and  polygraphs. 

Unpredictable  to  Adversary.  Making  your  system  unpredictable  prevents  the  adver¬ 
sary  from  making  educated  guesses  about  your  system  based  on  industry  standard 
configurations  and  components.  Techniques  include  pseudorandomization  and  un¬ 
common  configurations,  names,  locations,  equipment,  responsibilities,  etc.;  extreme 
heterogeneity  or  decentralization;  removing  documentation;  self-organizing  collec¬ 
tive  behavior;  goal-oriented  behavior;  specialization;  adaptive,  threat-based,  or  rule- 
based  activity;  communication  among  individuals;  beneficial  emergent  behavior  un¬ 
predictable  by  outsiders  (or  even  insiders);  and  varied  operating  procedures 
(hardware,  software,  staff) . 

Deception  for  Cl.  As  with  ISR,  deception  can  be  a  useful  (and  unexpected)  technique 
for  Cl  by  interrupting  information  flow  to  the  adversary.  Deception  techniques  for  Cl 
include  masking  an  item  and  its  particular  vulnerabilities;  masking  real  and  putting 
out  false  architecture,  design,  and  plan  information;  and  misleading  or  confusing  the 
adversary.  Masking  involves  camouflage;  low  observables;  mislabeling;  removing 
labels;  producing  false  associated  plans,  procedures,  instructions,  data,  or  other 
information;  network  anonymizers  (anonymous  searches,  IP  spoofing,  etc.);  emis¬ 
sion  shielding;  power  controls;  and  behavioral  camouflage  or  mimicry  (acting  more 
like  something  that  is  not  a  target).  Misleading  involves  stings;  cutouts  and  zombies; 
decoys;  disguises,  mimicry  (looking  more  like  something  that  is  not  a  target  but  is 
also  not  noise);  honeypots;  disinformation  (e.g.,  locations,  capabilities,  configura¬ 
tions,  procedures,  vulnerabilities,  etc.);  bluffs  and  feints;  and  disinformation.  Confus¬ 
ing  involves  oversaturation;  paralyzing  uncertainty;  “shoot-and-scoot”;  making  an 
attack  seem  easier  than  it  really  is;  producing  a  false  sense  of  security  in  the  adver¬ 
sary;  and  disinformation. 

Denial  of  ISR  and  Target  Acquisition.  Direct  denial  techniques  include  movement, 
shielding  or  access  filters,  and  jamming. 

Deterrence  and  Punishment 

The  last  general  category  of  security  techniques  involves  intimidating  adversaries  to 
reduce  their  willingness  to  attack  your  system  in  the  first  place. 

Deterrence.  Various  deterrence  techniques  for  information  systems  include  credible 
threats;  shows  of  force;  warnings,  peer  pressure,  psychological  operations  (PsyOps), 
and  tamper-evident  and  damage-evident  devices  (e.g.,  tape,  tabs,  indicators);  and 
proper  management  of  the  implementation  of  deterrence. 
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Preventive  and  Retributive  Information/Military  Operations.  Offensive  IO5  and 
military  operations  can  be  used  as  preventive  and  retributive  responses  to  attacks 
from  adversaries.  Operation  aspects  include  information  dissemination,  PsyOps, 
electronics  warfare,  physical  attack,  and  information  attack. 

Criminal  and  Legal  Penalties  and  Guarantees.  Techniques  that  can  be  employed 
include  bonding;  guarantees;  warrantees;  international  treaties  and  agreements;  uti¬ 
lize  non-repudiation  data;  and  penalties  for  attacks  and  damage  (including  by  insid¬ 
ers). 

Law  Enforcement;  Civil  Proceedings.  Finally,  enforcement  of  laws  is  important;  oth¬ 
erwise  their  threats  will  be  hollow.  Enforcement  aspects  include  international, 
national,  state,  and  local  authorities  and  courts;  utilizing  non-repudiation  data;  and 
proper  follow-through  and  management. 

HOW  SECURITY  TECHNIQUES  COMBINE  IN  COMMON  SECURITY 
APPROACHES 

The  following  examples  demonstrate  how  the  fundamental  mitigation  techniques 
listed  above  are  combined  in  common  security  approaches. 

First,  consider  INFOCONs.  Figure  5.2  shows  that  the  INFOCON  concept  is  an  objec¬ 
tive  threat  response  (or  preparation)  plan  that  allows  advanced  analysis  and 
arrangements.  However,  effective  use  of  INFOCONs  also  relies  on  the  ability  to 
monitor  and  assess  one’s  own  system  to  understand  what  the  threat  really  is  and  to 
ensure  that  the  INFOCON  level  is  neither  too  low  nor  too  high  given  the  real  threat. 
The  monitoring  and  assessment  aspect  is  important  to  prevent  the  known  concern 
that  the  INFOCON  level  may  be  set  too  high,  incurring  reduced  system  performance 
due  to  heightened  security. 

Second,  consider  “Indications  and  Warning”  (I&W)  systems  that  provide  intelligence 
on  attacks.  Figure  5.3  shows  that  I&W  relies  on  a  whole  host  of  ISR  and  self-aware¬ 
ness  techniques.  The  current  state  of  I&W  for  IO  relies  mostly  on  monitoring  and 
detection  techniques  within  the  defender’s  systems  (e.g.,  intrusion- detection  sys¬ 
tems,  network  monitors,  deception  techniques)  rather  than  on  intelligence  opera¬ 
tions  in  the  general  Internet  or  in  an  adversary’s  organizations  and  computer  sys¬ 
tems. 

Third,  consider  Computer  Emergency  Response  Teams  (CERTs)  and  other  related 
centers  that  coordinate  computer  security,  conduct  vulnerability  and  threat  analyses, 
provide  advisories,  organize  and  plan  security  responses,  and  implement  responses 
(both  planned  and  ad  hoc)  during  attacks.6  Figure  5.4  shows  that  CERTs  employ 


information  operations  can  also  be  referred  to  as  information  warfare  (IW). 

6Example  CERTs  include  the  “CERT®  Coordination  Center”  (CERT®CC)  (www.cert.org),  DoD-CERT 
(www.cert.mil),  Army  Computer  Emergency  Response  Team  (ACERT),  and  AIR  FORCE  Computer  Emer¬ 
gency  Response  Team  (AFCERT).  Related  centers  include  the  Federal  Computer  Incident  Response  Center 
(FedCIRC)  (www.fedcirc.gov),  the  National  Infrastructure  Protection  Center  (NIPC)  (www.nipc.gov),  Naval 
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Figure  5.2 — Security  Techniques  Supporting  INFOCONs 
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Figure  5.3 — Security  Techniques  Supporting  I&W 


Computer  Incident  Response  Team  (NAVCIRT),  and  the  NASA  Incident  Response  Center  (NASIRC)  (www- 
nasirc.nasa.gov). 
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Figure  5.4 — Security  Techniques  Supporting  CERTs 


centralization  to  coordinate  monitoring,  security  procedures  and  other  information, 
security  responses,  management,  and  communications  against  attacks. 

Fourth,  consider  firewalls  that  filter  information  and  requests  for  service  coming  into 
a  local  network  based  on  predefined  (and  sometimes  adaptive)  profiles.  Figure  5.5 
shows  that  firewalls  directly  implement  a  primary  means  of  controlling  exposure, 
access,  and  information  output,  but  effective  firewall  maintenance  depends  on  cur¬ 
rent  intelligence,  assessments  of  threats,  and  knowledge  of  what  is  happening  within 
one’s  system. 

Fifth,  consider  encryption  and  PKIs.  Figure  5.6  shows  that  they  provide  a  critical 
technical  means  for  controlling  exposure,  access,  and  output  by  verifying  identity 
and  controlling  exposure  of  information  during  transit. 
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Figure  5.5 — Security  Techniques  Used  in  Firewalls 
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Figure  5.6 — Security  Technique  Incorporating  Encryption  and  PKIs 
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Finally,  consider  isolation  and  air-gapped  networks.  Figure  5.7  shows  that  isolation 
and  air  gapping  are  other  technical  means  for  controlling  exposure,  access,  and  out¬ 
put.  The  most  critical  information  systems  often  use  these  approaches,  since  elec¬ 
tronic  filters,  firewalls,  and  encryption  schemes  can  be  compromised  with  enough 
effort.  Air  gapping  raises  the  level  of  security  so  that  other  access  means  have  to  be 
developed  by  the  adversary  (e.g.,  developing  physical  access,  using  insiders,  or  so- 
called  “chipping”  in  which  physical  devices  are  inserted  or  modified  to  facilitate 
future  access  or  damage). 
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Figure  5.7 — Security  Technique  Incorporating  Isolation  of  Systems 


Chapter  Six 

GENERATING  SECURITY  OPTIONS  FOR  VULNERABILITIES 


This  chapter  describes  how  step  4  of  the  VAM  methodology  maps  the  vulnerabilities 
presented  in  Chapter  Four  to  the  security  techniques  presented  in  Chapter  Five  to 
provide  specific  guidance  on  how  to  address  identified  vulnerabilities.  Next,  the 
chapter  describes  filtering  techniques  that  improve  the  appropriateness  of  the 
security  techniques  identified  in  the  matrix  to  a  particular  user  type  and  attack  stage. 
Chapters  Five  and  Six  describe  step  4  of  the  methodology  and  support  the  selection 
of  security  techniques  (step  5).  Finally,  the  chapter  provides  specific  examples  of  the 
kinds  of  specific  security  countermeasures  that  can  be  identified  for  specific,  com¬ 
mon  information  system  vulnerabilities  by  an  operational  evaluator  employing  the 
methodology. 

MAPPING  VULNERABILITIES  TO  SECURITY  TECHNIQUES 

Once  the  often-challenging  task  of  identifying  both  known  and  unknown  vulnera¬ 
bilities  has  been  achieved,  the  evaluator  must  identify  which  of  the  many  security 
techniques  identified  in  Chapter  Five  are  relevant  to  the  vulnerabilities  from  Chapter 
Four  identified  during  the  evaluation.  Rather  than  leaving  this  task  to  unguided 
personal  intuition  or  blind  brainstorming,  the  VAM  methodology  guides  the 
evaluator  by  explicitly  identifying  in  a  matrix  which  security  techniques  are  relevant 
for  each  vulnerability  attribute. 

Security  Techniques  That  Address  Vulnerabilities 

Table  6.1  shows  the  large  matrix  in  the  methodology  that  relates  vulnerability  prop¬ 
erties  (see  Chapter  Four)  along  the  left  column  to  the  security  techniques  (see  Chap¬ 
ter  Five)  across  the  top  row.  The  kinds  of  relationships  between  individual  vulnera¬ 
bility  properties  and  security  techniques  are  represented  by  numeric  values  (see  Fig¬ 
ure  6.1).  These  numeric  values  were  determined  by  experience  and  judgment  about 
the  logical  relationships  between  broad  categories  of  vulnerabilities  and  techniques. 
The  reasoning  behind  each  value  is  documented  in  the  Appendix. 
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Table  6.1 

The  Vulnerability  to  Security  Technique  Matrix 
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NOTE:  The  key  for  this  table  is  in  Figure  6.1. 
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0:  be  facilitated  by  vulnerability 
-1 :  incur  vulnerability  (secondary) 
-2:  incur  vulnerability  (primary) 


Figure  6. 1 — Values  Relating  Vulnerabilities  to  Security  Techniques 


When  a  security  technique  has  the  potential  to  mitigate  a  vulnerability,  the  matrix 
contains  a  numeral  2  or  7  at  the  intersection  point.  A  2  indicates  that  the  security 
technique  is  a  primary  mitigation  candidate,  and  a  7  indicates  that  the  technique  is  a 
secondaiy  mitigation  candidate  (recall  Figure  3.4].  Therefore,  when  one  identifies  a 
vulnerability,  he  or  she  can  look  across  the  row  and  see  what  security  techniques 
could  be  of  primary  and  secondary  relevance  to  that  vulnerability  by  looking  for 
techniques  that  have  a  2  or  7  (respectively)  in  its  column  for  the  vulnerability  row. 

For  example,  in  the  enlargement  in  Figure  6.1,  an  evaluator  with  a  Singularity  vul¬ 
nerability  should  first  consider  Heterogeneity,  Redundancy,  Decentralization;  and 
W&A,  SW/HW  Engineering,  Evaluations,  Testing  to  help  mitigate  the  singularity.1 
Centralization  may  be  considered  as  a  secondary  candidate  once  the  evaluator 
considers  all  the  primary  candidates. 

Security  Techniques  That  Incur  Vulnerabilities 

Interestingly,  security  techniques  can  also  incur  new  vulnerabilities  when  they  are 
implemented.  These  cases  are  noted  in  the  matrix  using  negative  numerals  -2  and  -7 


1  Other  techniques  are  also  rated  as  primary  using  a  2  but  are  not  visible  in  the  enlargement. 
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at  the  intersection  point.  A  -2  indicates  a  primary  caution  where  the  security  tech¬ 
nique  often  incurs  the  vulnerability,  and  a  -1  indicates  a  secondary  caution.  There¬ 
fore,  when  one  considers  any  security  technique,  he  or  she  should  look  down  the 
entire  column  for  that  technique  and  see  what  vulnerability  cautions  can  be  of  pri¬ 
mary  and  secondary  relevance  to  that  technique.  This  identification  can  be  of  use 
regardless  of  the  driving  factor  for  the  security  technique  and  can  help  evaluators 
audit  existing  security  programs  in  searching  for  hidden  vulnerabilities. 

For  example,  in  the  enlargement  in  Figure  6.1,  an  evaluator  considering  the  imple¬ 
mentation  of  a  Centralization  effort  (or  looking  for  vulnerabilities  that  may  be  pre¬ 
sent  due  to  existing  centralizations)  is  given  (among  other  things)  a  primary  caution 
(- 2 )  that  Centrality  problems  may  be  introduced.2  The  evaluator  is  also  given  a  sec¬ 
ondary  caution  (-1)  that  Homogeneity  may  be  introduced,  since  centralization  efforts 
often  involve  standardization  of  equipment,  software,  human/social  structures,  and 
infrastructure  reliance. 

Vulnerability  Properties  Can  Sometimes  Facilitate  Security  Techniques 

Finally,  in  constructing  the  matrix  we  noticed  instances  in  which  a  “vulnerability” 
might  have  beneficial  side  effects  that  facilitate  security  techniques.  These  instances 
are  noted  with  the  numeral  0  at  the  intersection  point  between  the  vulnerability 
property  and  security  technique. 

An  obvious  example  is  the  fact  that  Centrality  facilitates  Centralization,  since  the 
concept  can  be  viewed  both  as  a  potential  vulnerability  and  a  technique  for  address¬ 
ing  problems.  A  less  obvious  example  is  when  Homogeneity  can  facilitate  both  Static 
and  Dynamic  Resource  Allocation  by  providing  a  uniform  set  of  system  components 
that  are  more  easily  interchanged  and  granted  responsibilities.  Homogeneity  can  also 
facilitate  Rapid  Recovery  and  Reconstitution  since  interchangeable  parts,  common 
spares,  and  reduced  logistics  allow  faster  recovery.  In  a  final  example,  Predictability 
can  be  exploited  by  Deception  for  ISR  techniques  to  observe  how  an  adversary  reacts 
to  predictable  situations,  yielding  clues  to  their  tool  set  and  sophistication. 

The  matrix  does  not  identify  facilitative  relationships  between  security  techniques, 
but  they  do  exist.  Recall  the  examples  in  Chapter  Five  of  security  concepts  (e.g., 
INFOCONs,  I&W,  CERTs,  firewalls)  that  rely  on  the  combined  effect  from  different 
security  techniques  (see  Figures  5.2,  5.3,  5.4,  and  5.5,  respectively). 

Striking  a  Balance 

The  interplay  between  security  techniques  that  mitigate  vulnerabilities  and  security 
techniques  that  incur  vulnerabilities  demonstrates  the  competing  nature  of  concerns 
in  the  security  world.  Too  much  of  a  good  thing  can  be  damaging  in  the  security 
world  as  well.  There  are  usually  balances  that  must  be  struck 


2Centrality  can  be  both  a  vulnerability  and  a  positive  security  technique. 
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•  when  weighing  the  investments  in  system  functionality  versus  security 

•  among  degrees  of  implementation  of  a  security  technique 

•  between  competing  goals  and  characteristics  in  security 

•  among  the  added  costs  of  implementing  a  security  approach  to  minimize  or  pre¬ 
vent  adding  vulnerabilities  and  the  security  benefits  from  the  implementation. 

For  example,  in  the  enlargement  in  Figure  6.1,  an  evaluator  trying  to  deal  with  a  Sin¬ 
gularity  should  consider  Decentralization  (among  other  things),  but  decentralization 
may  introduce  Separability  problems  (primary  concerns),  as  well  as  Logic / 
Implementation  Errors  and  Design  Sensitivity/Fragility  problems  (secondary  con¬ 
cerns)  .  The  evaluator  needs  to  weigh  the  singularity  risks  against  the  costs  and  risks 
of  decentralization  implementation  options.  Can  decentralization  be  implemented 
to  address  the  particular  type  of  singularity?  Can  decentralization  be  implemented  in 
such  a  way  to  minimize  or  prevent  logic  or  implementation  errors  and  design  sensi¬ 
tivities  or  fragilities?  In  many  cases,  the  awareness  of  these  cautions  can  inform  their 
design  and  implementation  of  the  specific  mitigation  approaches  taken,  but  they 
should  be  explicitly  considered  to  balance  the  overall  risk  posture  of  the  information 
system. 

Design  and  Usage  Considerations 

These  relationships  do  not  specify  the  type  of  system  objects  possessing  the  vulner¬ 
abilities,  specifics  about  the  object  implementation,  and  the  general  security  posture 
in  the  system.  Therefore,  detailed  information  about  the  system  under  study  and  the 
appropriateness  of  security  options  must  supplement  the  general  knowledge 
reflected  in  the  matrix.  As  a  result,  the  matrix  forms  a  guide  to  aid  the  evaluator 
through  the  huge  space  of  options  rather  than  a  predefined  prescription.  In  specific 
situations,  vulnerabilities  may  also  benefit  from  the  use  of  security  techniques  un¬ 
valued  in  the  matrix,  so  at  times  one  may  want  to  reach  beyond  the  techniques  called 
out  in  the  matrix.  New  categories  arising  from  security  research  will  need  to  be  added 
to  the  matrix  over  time. 

REFINING  THE  SECURITY  SUGGESTIONS 

For  each  vulnerability  property,  the  methodology  matrix  displayed  in  Table  6.1 
identifies  a  rather  large  number  of  primary  and  secondary  security  techniques  of 
potential  relevance  to  consider.  As  the  number  of  vulnerabilities  increases,  an  almost 
unmanageable  set  of  suggestions  is  generated.  Although  the  VAM  matrix  is  an 
improvement  over  methodologies  that  do  not  generate  suggestions  that  help  the 
evaluator  reason  through  the  security  problem,  additional  help  is  needed  to  refine 
the  selection  process.  Also,  many  of  the  security  suggestions  may  be  generally 
appropriate  but  beyond  the  purview  and  authority  of  the  specific  evaluator  using  the 
methodology,  complicating  the  usability  of  the  raw  matrix.  Therefore,  to  focus  the 
evaluator’s  attention  on  the  most  relevant  security  techniques,  the  following  filtering 
approaches  have  been  developed  based  on  the  job  role  of  the  evaluator  conducting  a 
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security  assessment  and  the  distinction  of  supporting  stages  in  an  information  sys¬ 
tem  attack  as  separate  from  the  core  attack  (or  failure)  vulnerability. 

Evaluator  Job  Roles 

The  first  technique  for  filtering  security  suggestions  utilizes  the  fact  that  there  are 
different  job  roles  an  evaluator  plays;  security  suggestions  can  be  filtered  or  elimi¬ 
nated  if  they  are  not  usable  by  the  evaluator  because  of  his  or  her  responsibilities  and 
authority.  The  methodology  currently  employs  three  evaluator  job  role  categories: 
operational,  development,  and  policy.  Operational  evaluators  include  system  users, 
administrators,  and  managers  who  are  either  responsible  for  security  or  have  con¬ 
cerns  about  the  security  of  the  systems  they  use.  Development  evaluators  include 
research,  development,  testing,  and  system  engineers  responsible  for  creating  and 
configuring  the  information  system  but  are  not  engaged  in  its  operational  use.  Policy 
evaluators  specify  the  overall  system  needs,  requirements,  and  operating  proce¬ 
dures — often  in  the  context  of  the  larger  use  of  the  information  systems.  The  list  of 
evaluator  types  could  be  expanded  or  customized  in  the  future,  but  these  three  types 
have  been  useful  to  date. 

The  first  three  rating  columns  in  Table  6.2  and  Table  6.3  identify  which  security 
techniques  are  strongly  or  weakly  relevant  to  these  three  evaluator  job  roles.  Strongly 
relevant  security  techniques  are  rated  a  2  while  weakly  relevant  security  techniques 
are  rated  a  1.  For  example,  Table  6.2  shows  that  Non-Repudiation,  Management,  and 
Threat  Response  Structures  and  Plans  are  strongly  relevant  (rated  2)  to  Operational 
evaluators  (first  rating  column),  since  operational  individuals  and  organizations  can 
monitor  users  and  access,  establish  and  enforce  management  tools  to  improve 
security,  and  establish  procedures  and  agreements  to  respond  to  threats  and  failures. 
Control  of  Exposure,  Access,  and  Output  is  less  relevant  (rated  1 )  because  operational 
individuals  and  organizations  can  implement  and  control  physical  or  cyber  access 
but  can  be  constrained  in  the  design  and  implementation  of  software  and  procedures 
by  the  designs  or  policies  implemented  by  others.  So,  for  example,  an  operational 
user  for  which  the  main  matrix  (Table  6.1)  suggests  that  three  possible  techniques — 
(i)  Heterogeneity,  (ii)  Non-Repudiation,  and  (iii)  Control  of  Exposure,  Access,  and 
Output — may  help  to  mitigate  a  vulnerability  of  concern  would  first  consider  Non¬ 
repudiation,  since  it  rates  as  strongly  relevant  (2)  in  Table  6.2.  Control  of  Exposure, 
Access,  and  Output  would  be  considered  second  since  it  rates  as  weakly  relevant  (1) 
in  Table  6.2.  The  third  matrix  suggestion  ( Heterogeneity )  would  be  considered  last 
because  it  has  no  rating  in  Table  6.2. 

It  appears  that  developers  have  the  most  flexibility  in  security  choices  (i.e.,  have  the 
most  2s  in  their  rating  columns),  since  they  design  the  architecture,  physical  plant, 
and  infrastructure  dependencies  and  relationships  within  the  constrains  of  policies 
that  are  usually  quite  broad.  However,  developers  cannot  dictate  to  operational  users 
exactly  how  they  will  use  and  manage  their  information  systems.  Thus,  each  job  type 
has  its  own  realm  of  responsibility,  authority,  and  thus  flexibility. 
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Table  6.2 

Resilience  and  Robustness  Techniques  for  Evaluator  lob  Roles  and  Attack  Components 
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Table  6.3 

ISR,  Cl,  and  Deterrence  Techniques  for  Evaluator  lob  Roles  and  Attack  Components 
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Attack  Components 

The  second  technique  for  filtering  security  suggestions  utilizes  the  fact  that  while  a 
failure  may  have  a  single  vulnerability  source,  an  attack  on  a  system  involves  distinct 
components  where  security  techniques  can  be  employed.  Knowledge,  access,  and 
target  vulnerabilities  are  required  in  any  successful  attack.  Complete  prevention  of 
any  one  of  these  three  components  will  deny  a  successful  attack,  and  protections 
across  these  components  minimize  the  overall  risk.  Two  other  important  attack 
components — non-retribution  and  the  ability  to  assess  the  success  of  an  attack — 
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while  not  critical  to  the  success  of  an  attack  are  so  important  to  many  attackers  that 
an  attack  can  be  prevented  if  these  components  are  denied. 

Knowledge  includes  acquiring  and  understanding  information  about  the  target  sys¬ 
tem,  including  general  configuration  information,  security  postures  and  procedures 
of  the  defender,  ways  to  achieve  access  to  the  system,  knowledge  about  the  target 
vulnerability  to  be  exploited,  knowledge  about  the  defender’s  indications  and  warn¬ 
ing  systems,  procedures  the  defender  uses  to  identify  the  attacker,  and  information 
to  support  attack  assessments. 

Access  to  the  attacking  system  is  required  to  acquire  knowledge,  perform  the  actual 
attack  on  the  target,  and  assess  the  success  of  the  attack.  Access  could  be  gained 
through  each  type  of  object  (physical,  cyber,  human/social,  and  infrastructure)  and 
include  physical  access  or  proximity  (e.g.,  access  to  restricted  areas  or  electromag¬ 
netic  access);  computer,  communication,  or  control  networks;  agents  with  inside 
access;  and  vital  infrastructure  systems. 

The  target  vulnerability  or  vulnerabilities  to  be  exploited  in  the  attack  result  from 
design  weaknesses  and  behavioral  sensitivities  that  can  be  exploited  by  an  attacker. 
For  vulnerabilities  arising  from  natural  or  accidental  causes,  the  target  vulnerability 
category  is  the  sole  level  of  concern. 

Non-retribution,  while  not  critical  to  the  success  of  every  attack,  is  often  very  impor¬ 
tant  to  such  attackers  as  nation-states  that  do  not  want  their  information  attacks 
known,  as  well  as  organizations  that  worry  about  reprisals  due  to  their  own  vulner¬ 
abilities. 

Finally,  complex  organizations  that  rely  on  information  attacks  as  components  in 
larger  operations  need  the  ability  to  assess  the  effectiveness  of  their  attacks  (e.g., 
when  other  operations  cannot  proceed  without  knowing  the  success  of  the  attack). 

Table  6.4  lists  the  major  ways  that  an  attacker  can  accomplish  each  component  of  an 
attack  (except  the  target  vulnerability  itself  which  is  often  a  property  of  the  informa¬ 
tion  system  itself  and  not  under  the  purview  of  the  attacker).  These  methods  are  dis¬ 
tributed  across  the  four  major  system  objects  (physical,  cyber,  human/social,  and 
infrastructure).  Table  6.5  identifies  which  vulnerability  properties  can  be  exploited  in 
each  of  the  five  attack  components. 

Attack  Stage  Relevance  by  Evaluator  Job  Role 

Taken  together,  evaluator  role  and  attack  stage  filtering  yields  the  following  emergent 
effect  that  helps  refine  security  suggestions.  These  filters  focus  attention  on  attack 
components  in  which  the  evaluator  has  more  ability  to  implement  protections  and 
countermeasures.  Thus,  operational  users  generally  have  greater  control  over, 
knowledge  of,  and  access  to  the  systems  than  over  their  architecture  and  implemen¬ 
tations.  Developers  can  adjust  the  hardware  and  software  to  minimize  vulnerabilities 
in  the  architecture  and  implementations  but  have  less  influence  over  use,  knowl¬ 
edge,  and  access.  Finally,  policymakers  set  general  guidance  and  constraints  in 
design  and  operation  but  do  not  specify  actual  implementation  details. 


Table  6.4 


Methods  for  Accomplishing  Each  Component  of  an  Attack 
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Object  of  Vulnerability 

Physical 

Cyber 

Human/Social 

Enabling  Infrastructure 

Attack  Stage 

Hardware  (Data  Storage,  Input/Output, 
Clients,  Servers),  Network  and 
Communications,  Locality 

Software,  Data,  Information, 
Knowledge 

Staff,  Command,  Management, 
Policies,  Procedures,  Training, 
Authentication 

Ship,  Building,  Power,  Water,  Air, 
Environment 

Knowledge 

Viewable,  blueprints,  standard 
architecture,  purchase  orders, 
deductable  from  behavior  or  first 
principles  (e.g.,  physics);  hacker 
bulletin  boards;  chat  rooms 

Nmap  port  scan,  open  source 
information  (e.g.,  Web);  source  code; 
reverse  engineering;  virus/worm 
reports;  hacker  bulletin  boards;  chat 
rooms;  behavior  of  the  system;  blue 
prints;  standard  architectures;  sniffers 

Org.  charts;  “social  engineering”; 
HUMINT 

Viewable,  blueprints,  standard 
architecture,  purchase  orders, 
deductable  from  behavior  or  first 
principles  (e.g.,  physics);  hacker 
bulletin  boards;  chat  rooms;  Nmap 
port  scan,  open  source  information 
(e.g.,  Web);  source  code;  reverse 
engineering;  virus/worm  reports; 
hacker  bulletin  boards;  chat  rooms; 
behavior  of  the  system;  blue  prints; 
standard  architectures;  sniffers;  Org. 
charts;  “social  engineering”;  HUMINT 

Access 

Insider;  visitors;  neighborhood 

Networks;  EW 

Phone;  email;  physical  presence; 
agents;  signals 

Insider;  visitors;  neighborhood; 
networks;  EW;  phone;  email;  physical 
presence;  agents;  signals 

Non-Retribution 

Agents;  disguises;  camouflage 

Spoofing;  zombies 

Agents;  voice/communication 
disguises;  camouflage 

Agents;  disguises;  camouflage; 
spoofing;  zombies;  agents; 
voice/communication  disguises; 
camouflage 

Assess 

Viewable,  deductable  from  behavior 
or  first  principles  (e.g.,  physics); 
insider;  visitors;  neighborhood 

Nmap  port  scan,  open  source 
information  (e.g.,  Web);  news; 
virus/worm  reports;  hacker  bulletin 
boards;  chat  rooms;  behavior  of  the 
system;  sniffers;  networks 

“Social  engineering”;  HUMINT; 
phone;  email;  physical  presence; 
agents;  signals 

Viewable,  deductable  from  behavior  or 
first  principles  (e.g.,  physics);  insider; 
visitors;  neighborhood;  Nmap  port 
scan,  open  source  information  (e.g., 
Web);  news;  virus/worm  reports; 
hacker  bulletin  boards;  chat  rooms; 
behavior  of  the  system;  sniffers; 
networks;  “social  engineering"; 
HUMINT;  phone;  email;  physical 
presence;  agents;  signals 
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EXAMPLE  SECURITY  OPTIONS  ARISING  FROM  THE  USE  OF 
THE  METHODOLOGY 

The  following  shows  the  kind  of  security  options  that  an  evaluator  from  an  opera¬ 
tional  organization  can  generate,  using  the  methodology  as  an  analytical  guide  to 
addressing  security  concerns.  These  examples  involve  the  common  security  concerns 
presented  in  Chapter  Four  in  the  checklist  matrix  example  (see  Table  4.3).  These 
concerns  range  across  cyber,  physical,  and  human/social  object  of  information 
systems  for  a  number  of  different  vulnerability  attributes.  The  analysis  in  the 
examples  is  far  from  comprehensive,  but  it  illustrates  the  use  of  the  VAM  methodol¬ 
ogy  on  well-known  problems  in  the  information  security  field  and  the  types  of  spe¬ 
cific  security  strategies  that  may  come  out  of  the  analysis.  Some  security  ideas  are 
commonly  known,  while  others  are  novel. 

These  generic  examples  do  not  contain  specifics  related  to  an  actual  vulnerability  or 
more-specific  examples  of  security  techniques  that  address  the  vulnerabilities’ 
unique  characteristics.  Nevertheless,  they  help  to  demonstrate  how  the  methodology 
guides  the  evaluator  to  security  techniques,  and  the  kind  of  instantiations  of  the 
techniques  that  may  be  considered. 

For  each  example,  we  specify  the  vulnerability  attribute  and  object  type  followed  by  a 
short  description  of  the  vulnerability.  We  then  highlight  a  number  of  security  tech¬ 
nique  categories  suggested  by  the  matrix,  along  with  specific  mitigation  strategies 
within  the  categories  that  may  be  appropriate  for  the  particular  vulnerability  in 
question.  These  specific  mitigation  strategies  arise  both  from  the  general  list  of 
security  technique  examples  described  in  Chapter  Five  and  from  the  novel  counter¬ 
measures  that  came  to  us  when  we  considered  the  security  technique  category 
afresh. 

Insider  Threat 

Vulnerability  Attribute:  Malevolence. 

Type  of  Target:  Human/social. 

It  is  widely  believed  that  the  “insider  threat’’  (malevolent  behavior  by  a  trusted  per¬ 
son  with  approved  access  to  a  critical  information  system)  is  the  greatest  threat  to  the 
security  of  information  systems.  The  “insider”  might  be  someone  with  a  grudge,  or 
someone  co-opted  by  an  enemy  through  blackmail,  bribes,  or  the  like. 

Potential  Relevant  Mitigation  Strategies: 

Control  of  exposure,  access,  and  output.  Ensure  that  “insiders”  have  only  that  access 
within  the  network  and  physical  areas  needed  for  their  jobs. 

Non-repudiation.  Maintain  access  and  permissions  audit  logs  to  allow  prosecution  of 
anyone  violating  authorized  procedures. 


Design/, 
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Table  6.5 

Vulnerability  Exploitation  by  Attack  Component 


RAND  MR1 601 -table6. 5 


|  Strongly  relevant 
8H  Weakly  relevant 


Logic/ 

Implementation 
Errors;  Fallibility 

Design  Sensitivity/ 

Fragility/Limits/ 

Finiteness 


Unrecoverability 


Predictability 


Non-Retribution 
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General  management.  Ensure  that  procedures  are  in  place  (e.g.,  security  campaigns 
and  reminders)  to  alert  staff  of  the  dangers  of  insider  threats  (including  their  own 
unwitting  recruitment)  and  other  threats  to  critical  information  systems. 

Self-awareness,  monitoring,  and  assessments.  (See  “Attack  detection  . . .  below.  Con¬ 
sider  especially  the  use  of  intrusion  detection  software  within  the  local  area  networks 
[LANs].) 

Deception  for  intelligence,  surveillance,  and  reconnaissance.  Create  “honeypots”  (e.g., 
files  containing  bogus  but  attractive  information)  within  critical  systems  so  that 
accessing  these  honeypots  will  generate  an  alert  stating  that  an  individual  is  engag¬ 
ing  in  suspicious  behavior  and  should  be  monitored. 

Attack  detection,  recognition,  damage  assessment,  and  forensics  (self  and  foe).  Con¬ 
sider  the  use  of  real-time  “intrusion  detection”  software  to  detect  abnormal  behavior 
that  violates  a  set  of  preprogrammed  rules  or  exhibits  statistical  abnormalities. 
Review  access  and  audit  logs  for  suspicious  behavior. 

Unpredictable  to  adversary.  Limit  knowledge  of  system  configurations,  key  compo¬ 
nent  locations,  and  key  system  dependencies — even  within  “trusted”  staff. 

Deterrence.  Use  criminal  and  legal  penalties  (see  below)  against  offenders  to  deter 
others. 

Criminal  and  legal  penalties  and  guarantees.  Ensure  that  criminal  and  legal  penalties 
for  insider  attacks  are  well  developed,  used  when  appropriate,  and  thus  act  as  a 
deterrence. 

Law  enforcement,  civil  proceedings.  Use  law  enforcement  to  punish  illegal  behavior 
as  a  deterrence. 

Inability  to  Handle  Distributed  Denial-of-Service  Attacks 
Vulnerability  Attribute:  Behavioral  sensitivity/fragility. 

Type  of  Target:  Cyber. 

One  of  the  most  difficult  kinds  of  cyber  attack  to  handle  is  a  DDoS  attack,  wherein 
hundreds  or  thousands  of  different  computers  bombard  a  specific  network  router  or 
other  component  with  packets  or  requests  for  service — usually  ones  with  erroneous 
information  that  require  additional  time  for  processing.  Information  networks  must 
be  especially  configured  and  designed  if  they  are  to  thwart  (to  the  extent  possible) 
this  kind  of  attack  that  depends  on  behavioral  characteristics  and  sensitivities  of  the 
network(s) . 

Potential  Relevant  Mitigation  Strategies: 

Decentralization.  Consider  using  parallel  or  backup  servers  that  can  take  over  when 
the  primary  server  is  incapacitated  due  to  a  DDoS  attack.  Use  rotating  server 
responsibilities  to  present  an  unpredictable  moving  target  to  the  DDoS  attacker. 
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W&A,  software/hardware  engineering,  evaluations,  testing.  Test  the  network  (e.g., 
through  “red  teaming”  and  other  means)  for  robustness  against  DDoS  attacks. 

Control  of  exposure,  access,  and  output.  Establish  control  points  at  various  positions 
in  the  network  where  filters  can  be  installed  for  DDoS  traffic. 

Fault,  uncertainty,  validity,  and  quality  tolerance  and  graceful  degradation.  Consider 
means  to  allow  graceful  degradation  of  the  networks  under  DDoS  attack  (e.g.,  by 
reducing  all  other  IP  traffic  from  other  applications). 

Dynamic  resource  allocation.  Provide  a  rapid  way  to  cut  off  DDoS  traffic  further  up 
the  network  chain  (e.g.,  at  the  gateway  to  your  Internet  service  provider). 

Self-awareness,  monitoring,  and  assessments.  Provide  monitoring  for  early  warning  of 
DDoS  attacks  at  all  levels  of  gateways  within  critical  IP  networks;  have  preplanned 
procedures  in  place  for  reaction  when  such  monitoring  detects  a  DDoS  attack. 

IP  Spoofing 

Vulnerability  Attribute:  Gullibility/  deceivability/  naivete. 

Type  of  Target:  Cyber. 

To  “spoof”  an  IP  address,  within  a  packet  or  message,  means  to  substitute  an  erro¬ 
neous  address  in  the  place  where  a  valid  one  should  appear.  By  this  means,  it 
becomes  difficult  to  ascertain  the  true  sender  of  an  information  packet  or  session, 
and  therefore  difficult  to  permit  various  forms  of  attack  that  disguise  their  source. 

Potential  Relevant  Mitigation  Strategies: 

Hardening;  also  control  of  exposure,  access,  and  output.  Consider  enforcing  various 
firewall  precautions  and  rules — for  example,  disallowing  any  IP  packets  to  be  emitted 
from  a  local  network  with  source  IP  addresses  not  valid  for  that  network. 

Threat  response  structures  and  plans.  When  any  host  (computer)  in  the  system 
determines  that  invalid  IP  addresses  are  being  used  by  some  sender,  a  preplanned 
response  can  be  initiated  to  alert  other  hosts  to  block  transmissions  from  the 
addresses. 

Adaptability  and  learning.  Firewalls,  routers,  and  other  devices  operating  key  IP  net¬ 
works  may  be  adaptable  so  that  responses  to  known  IP-spoofing  attacks  can  be 
quickly  instituted  throughout  the  network. 

Vaccination.  (See  “Threat  response  structures  and  plans”  above.)  As  soon  as  a  bogus 
IP  address  is  discovered,  other  hosts  and  routers  in  the  network  could  be 
“vaccinated”  against  it,  as  a  rudimentary  form  of  “immunological  defense  system.” 

Self-awareness,  monitoring,  and  assessments.  Firewalls,  routers,  and  similar  devices 
must  constantly  be  alert  to  bogus  IP  addresses  so  that  remedial  steps  such  as  those 
above  can  be  taken. 
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Inability  to  Detect  Changes  to  IP  Net,  Making  IP  Masking  Possible 
Vulnerability  Attribute:  Self-unawareness  and  unpredictability. 

Type  of  Target:  Cyber. 

If  an  IP  network  does  not  have  active  monitoring  programs  and  tools  to  allow  per¬ 
sonnel  to  ascertain  whether  a  new  host  (IP  address)  has  been  inserted,  or  removed, 
from  the  net,  then  it  could  be  possible  for  someone  to  insert  an  unauthorized  laptop 
or  another  device  onto  a  network  connection  and  download  information  into  that 
device.  This  danger  is  especially  prevalent  for  wireless  networks,  where  the 
“connection”  can  be  from  a  location  away  from  visible  network  ports  or  even  outside 
the  organization’s  building.  This  is  a  lack  of  “self-awareness”  of  the  network  configu¬ 
ration,  and  changes  to  it,  during  its  operation. 

Potential  Relevant  Mitigation  Strategies: 

Centralization.  Institute  a  central,  real-time  network  monitoring  activity,  with  sen¬ 
sors  and  application  programs  capable  of  detecting  and  displaying  any  changes  to 
the  network  configuration. 

Self-awareness,  monitoring,  and  assessments.  Through  appropriate  monitoring  tools 
and  techniques,  the  network  should  be  aware  of  any  changes  to  its  configuration, 
and  highlight  those — at  the  time  they  occur — in  a  display  or  signal  to  network  opera¬ 
tors. 

Centralized  Network  Operations  Centers 
Vulnerability  Attribute:  Centrality. 

Type  of  Target:  Physical. 

Network  operations  centers  can  contain  many  vital  physical  components  (e.g.,  key 
equipment  and  backups)  in  one  central  location.  As  such,  a  physical  attack  could 
disable  not  only  primary,  but  also  backup,  routers  and  key  communications  equip¬ 
ment. 

Potential  Relevant  Mitigation  Strategies: 

Decentralization.  Consider  providing  multiple  support  centers.  Do  not  store  backup 
equipment  in  the  same  physical  location  as  main  equipment.  Provide  multiple 
access  points  where  routers  can  be  placed  on  the  physical  LAN  cables. 

Control  of  exposure,  access,  and  output.  Restrict  physical  access  to  the  room  based  on 
need-to-use.  Provide  protective  shielding  or  structure  (physical  and  electrical)  to 
help  prevent  accidental  or  deliberate  changes,  damage,  etc.  Put  tamper-resistant 
tabs  on  the  panel  and/or  shielding.  Keep  backup  equipment  off-line  to  provide  pro¬ 
tection  until  needed. 

Hardening.  Provide  protective  shielding  or  structure  (physical  and  electrical)  to  help 
prevent  accidental  or  deliberate  changes,  damage,  etc.  Put  tamper-resistant  tabs  on 
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the  panel  and/or  shielding.  Keep  backup  equipment  off-line  to  provide  protection 
until  needed. 

Threat  response  structures  and  plans.  Have  preplanned  procedures  for  recovery  to 
any  centralized  components. 

Rapid  reconstitution  and  recovery.  Generate  plans  on  how  to  manually  rebuild 
capability  for  vital  communications.  Develop  replacement  contingencies.  Examine 
local  ability  to  repair  systems.  Store  backup  equipment  and  configuration  informa¬ 
tion  in  a  different  location  that  is  not  likely  to  be  destroyed  in  the  same  physical 
attack. 

Common  Commercial  Software  and  Hardware  Are  Well  Known 
and  Predictable 

Vulnerability  Attribute:  Predictability. 

Type  of  Target:  Physical  and  Cyber. 

The  personal  computers,  workstations,  routers,  servers,  and  other  components  of 
critical  information  systems  are  often  heavily  based  on  commercial  products,  such  as 
Cisco  router  software;  Windows  NT;  Microsoft  Outlook,  Word,  Excel,  PowerPoint, 
etc.  As  such,  the  vulnerabilities,  organization,  and,  in  some  cases,  source  code  of 
such  programs  are  widely  known.  These  programs  are  thus  highly  predictable  in  that 
other  copies  of  them  can  be  tested  to  find  situations  (e.g.,  exceeding  the  capacity  of  a 
database)  in  which  their  performance  fails. 

Potential  Relevant  Mitigation  Strategies: 

Heterogeneity.  Consider  using  a  variety  of  COTS  software  and  hardware — for  exam¬ 
ple,  Netscape  in  addition  to  Internet  Explorer;  Netscape  mail  in  addition  to  Microsoft 
Outlook.  Then  a  virus  or  worm  capitalizing  on  a  well-known  flaw  may  not  infect  all 
systems  at  the  same  time. 

W&A,  software/hardware  engineering,  evaluations,  testing.  To  the  extent  possible, 
test  heavily  used  commercial  hardware  and  software  in  critical  information  systems 
for  vulnerabilities.  Use  “red  team’’  approaches  to  system  testing.  Use  “open  source” 
code  for  critical  operating  systems  and  applications  that  can  be  inspected  for  buried 
flaws.  (Note  that  the  many  users  in  the  open-source  community  already  search  for 
such  flaws  and  use  of  seasoned  open-source  code  inherits  the  benefits  of  their 
labors.) 

Management.  Ensure  that  any  available  patches  and  fixes  are  tested  and  installed 
rapidly  as  soon  as  they  become  available. 

Immunological  defense  systems.  Establish  protocols  to  rapidly  share  information  on 
an  attack’s  reliance  on  standard  commercial-system  vulnerabilities  and  configura¬ 
tions. 
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Deception  for  counterintelligence.  Provide  deceptive  files  (e.g.,  WIN  file  types  on 
UNIX  and  Macintosh  equipment  and  software)  to  make  it  harder  to  determine  the 
type  of  software  being  used,  especially  via  automatic  scanning  programs.  Place  sys¬ 
tem  files  in  unorthodox  places  or  store  them  under  different  names  (e.g.,  do  not  store 
UNIX  binaries  under  / bin;  do  not  store  system  files  under  “C:WINNT”  or  “C:Program 
Files”;  change  the  default  folder  name  for  email  attachments). 

Unpredictable  to  adversary.  Remove  information  about  the  type  of  software  used 
from  both  internally  and  externally  accessible  systems  when  possible. 

Standardized  Software 
Vulnerability  Attribute:  Homogeneity. 

Type  of  Target:  Cyber. 

The  heavy  use  of  standardized  software  for  routers  (e.g.,  Cisco  operating  system), 
servers  (e.g.,  Windows  NT),  and  PCs/workstations  (e.g.,  Windows  NT  or  Macintosh 
OS)  creates  a  very  homogeneous  information  and  communication  system.  Any  flaw 
in  one  of  these  designs  can  be  replicated  widely  within  the  information  system  and 
therefore  can  provide  a  common  vulnerability  across  the  system. 

Potential  Relevant  Mitigation  Strategies: 

Heterogeneity.  Consider  deliberate  use  of  alternative  software  (e.g.,  Linux,  Macintosh 
OS,  Sun  Solaris)  as  part  of  the  network  or  desktop  configuration  so  that  if  any  virus, 
worm,  or  other  cyberattack  ‘‘takes  down”  all  standard  systems  (e.g.,  Windows  NT 
running  Outlook),  then  these  other  systems  may  continue  operating  and  provide 
emergency  service  until  the  damage  is  contained,  isolated,  and  removed. 

W&A,  software/hardware  engineering,  evaluations,  testing.  To  the  extent  that  stan¬ 
dardized  (homogeneous)  system  components  are  widely  used  throughout  critical 
systems,  use  extra  testing  to  ensure  they  are  free  of  exploitable  flaws  to  the  extent 
possible. 

Hardening.  Dependence  on  standardized  software  should  trigger  extra  measures  to 
ensure  that  it  is  “hardened”  against  attack — for  example,  by  retaining  backup  copies 
of  critical  operating  systems  and  applications  in  a  “hard”  (unmodifiable)  medium, 
such  as  CD-ROM  or  DVD-R,  for  use  in  recovering  systems  after  an  attack. 

Fault,  uncertainty,  validity,  and  quality  tolerance  and  graceful  degradation.  Ensure 
that  standardized  software  is  “fault  tolerant”  and  degrades  gracefully  under  various 
types  of  attacks.  For  example,  software  might  shed  noncritical  applications  when  an 
attack  is  sensed  and  shut  various  firewall  options  to  help  thwart  a  cyberattack. 

Weaknesses  in  Router  or  Desktop  Applications  Software 
Vulnerability  Attribute:  Logic/implementation  errors;  fallibility. 

Type  of  Target:  Cyber. 
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Fundamental  design  or  implementation  flaws  in  standard  software  used  in  operating 
systems  (workstation  and  router)  and  desktop  applications  may  exist.  These  flaws,  if 
they  become  known  to  an  attacker,  could  provide  unauthorized  access  or  destruc¬ 
tion. 

Potential  Relevant  Mitigation  Strategies: 

Heterogeneity.  Use  a  diverse  set  of  servers  based  on  differing  software  (such  as  email 
programs)  and  operating  systems  (e.g.,  UNIX  in  addition  to  Windows  NT),  especially 
on  systems  with  higher  security  standards. 

W&A,  software/hardware  engineering,  evaluations,  testing.  Conduct  thorough  “red 
teaming”  and  testing  of  COTS  products  to  understand  inherent  vulnerabilities; 
develop  security  procedures  to  mitigate  vulnerabilities.  Ensure  proper  firewall  instal¬ 
lations  and  maintenance  at  boundaries  as  well  as  locally  (when  feasible).  Keep  up  to 
date  on  patches  and  fixes  as  they  become  available. 

Control  of  exposure,  access,  and  output.  Restrict  physical  access  to  key  equipment 
based  on  need-to-use,  helping  to  prevent  insider  or  intruder  cyber  attacks  and  acci¬ 
dents. 

General  management.  Ensure  that  all  procedures  to  protect  “root”  access  are  imple¬ 
mented  and  kept  up  to  date. 

Immunological  defense  systems.  Adopt  “immunological”  defensive  measures,  in 
which  one  system,  detecting  an  attack  or  flaw,  notifies  other  similar  systems  to 
increase  their  defenses  against  such  an  attack  or  flaw. 

Vaccination.  Have  a  central  location  automatically  “vaccinate”  systemwide  compo¬ 
nents  and  computers  with  patches  and  fixes  as  soon  as  they  become  tested  and 
available.  Be  careful  that  this  centralized  updating  procedure  is  well  protected  to 
prevent  an  easy  target  for  spreading  attacks  across  the  information  system  and  that 
patches  and  fixes  are  well  tested. 

Electronic  Environmental  Tolerances 

Vulnerability  Attribute:  Design  sensitivity/fragility/limits/finiteness. 

Type  of  Target:  Physical. 

Various  commercial  electronic  equipment  vital  to  network  communications  and 
computing  are  often  not  hardened  for  environmental  influences  (e.g.,  temperature, 
smoke,  humidity)  or  extreme  attack  means  (e.g.,  EMPs). 

Potential  Relevant  Mitigation  Strategies: 

Heterogeneity.  Consider  using  equipment  with  differing  ranges  of  environmental  tol¬ 
erances,  so  entire  capabilities  would  not  be  lost  under  certain  extreme  environmen¬ 
tal  conditions. 
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Redundancy.  Store  backup  equipment  in  sealed  containers,  perhaps  with  EMP- 
shielding.  Provide  local,  redundant  environmental  conditioning  equipment  for  sin¬ 
gular,  centralized  equipment  rooms. 

W&A,  software/hardware  engineering,  evaluations,  testing.  Test  and  make  available 
the  environmental  ranges  within  which  key  electronic  equipment  can  operate; 
attempt  to  procure  equipment  with  the  least  environmental  sensitivity. 

Control  of  exposure,  access,  and  output.  Install  positive  pressure  air  conditioning  to 
keep  smoke,  humidity,  or  other  environmental  hazards  from  entering  electronic 
environments — especially  those  with  singularities.  Install  EMP  shielding  for  critical 
equipment  and  for  a  subset  of  terminals  that  can  be  used  for  minimal  capability 
under  adverse  conditions. 

Hardening.  (See  “Install  EMP  shielding  ...”  and  “Store  backup  equipment  in  sealed 
containers ...”  above.) 

Self-awareness,  monitoring,  and  assessments.  Install  sensors  for  all  adverse  environ¬ 
mental  conditions  that  could  affect  electronic  equipment,  especially  those  that  are 
singular  or  centralized.  Have  prearranged  contingency  plans  for  when  environmen¬ 
tal  conditions  exceed  those  under  which  the  equipment  can  operate. 


Chapter  Seven 

AUTOMATING  AND  EXECUTING  THE  METHODOLOGY: 

A  SPREADSHEET  TOOL 


Manually  working  through  the  evolved  methodology’s  large  matrix,  evaluator  filters, 
and  attack-component  filters  is  laborious  for  an  evaluator  and  may  prevent  thorough 
or  careful  application  of  the  VAM  methodology.  Moreover,  looking  up  the  definitions 
of  the  various  vulnerabilities,  security  techniques,  and  attack  methods  during  the 
course  of  an  evaluation  can  be  daunting  as  well.  Therefore,  a  prototype  computer¬ 
ized  tool  has  been  developed  and  implemented  to  assist  in  using  the  methodology. 
This  tool  is  implemented  as  a  Microsoft  Excel  spreadsheet  using  Visual  Basic  algo¬ 
rithms  to  perform  information  lookups  as  well  as  simple  scoring  of  vulnerability  risks 
based  on  the  inputs  from  the  evaluator.1 

Even  with  this  tool,  it  is  important  to  realize  that  comprehensive  vulnerability 
assessments  cannot  be  fully  automated.  Automated  network  and  computer  scanning 
software  and  methodologies  can  identify  specific,  known  vulnerabilities  such  as  back 
doors,  open  ports,  missing  patches,  throughput  limitations,  operating  anomalies, 
and  the  like.  However,  automated  tools  cannot  conduct  a  top-down  review  of 
properties  that  have  yet  to  be  exploited  or  which  involve  the  full  range  of  physical, 
human/social,  and  infrastructure  configurations  and  behaviors.  Their  fidelity 
depends  greatly  on  the  breadth  of  their  threat  or  operating  models,  the  inputs  they 
generate,  and  the  outputs  they  observe.  Comprehensive  reviews  often  require  the 
deep  knowledge  and  experience  of  people  intimately  involved  in  the  information 
system  and  its  operations.  Our  methodology  is  an  aid  to  evaluators,  yet  the 
automated  tool  helps  the  evaluator  deal  with  the  large  amount  of  information  in  the 
methodology. 

INITIAL  STEPS  PERFORMED  MANUALLY 

Steps  1  and  2  of  the  methodology  (identifying  the  critical  information  functions  and 
identifying  the  critical  information  systems  supporting  these  functions)  are  executed 
manually  through  evaluator  assessments  and  reviews  of  the  information  system  in 
question.  Although  complex  in  their  own  right,  these  two  steps  often  require 


1Nothing  inherent  about  Excel’s  functionality  was  required  to  implement  the  prototype  tool.  It  was  chosen 
simply  as  a  convenient  and  commonly  available  spreadsheet  application  in  which  the  required  algorithms 
could  be  implemented.  A  Web-based  tool  might  be  another  useful  platform  for  implementing  the  tool, 
given  its  ease  of  access  and  availability  (see  Chapter  Eight). 
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organizational  investigations  and  considerations  of  those  that  are  hard  to  structure 
and  facilitate  with  a  small  tool.  Such  processes  as  OCTAVE  (Alberts  et  al.,  1999,  2001) 
have  forms  and  procedures  that  can  be  considered  for  these  steps,  and  the  Common 
Criteria  (ISO  15408)  specifies  a  breadth  of  issues  and  considerations  that  should  be 
addressed  by  selected  processes. 

VULNERABILITIES  GUIDED  BY  AND  RECORDED  ON  A  FORM 

For  step  3,  a  worksheet  form  is  available  in  the  VAM  tool  (see  Table  4.2).  This 
worksheet  should  be  completed  for  each  information  system  (or  major  subsystem) 
under  review  and  at  various  architectural  levels  within  the  system.  This  form 
facilitates  the  execution  of  step  3  of  the  methodology  (identifying  the  vulnerabilities 
in  the  critical  systems)  by  providing  the  evaluator  with  the  full  list  of  vulnerability 
properties  in  the  rows  and  listing  the  four  different  object  types  in  an  information 
system  (physical,  cyber,  human/social,  and  infrastructure)  as  columns.  Using  this 
form  helps  to  ensure  a  broad  review  of  target  vulnerabilities  across  all  these 
dimensions  rather  than  a  simple  recording  of  the  standard  types  of  vulnerabilities 
that  come  to  mind  or  those  that  are  commonly  raised  in  the  evaluator’s  organization. 

Remember  also  that  the  vulnerability  to  security  technique  matrix  identifies  cautions 
when  security  techniques  may  incur  vulnerabilities.  The  evaluator  may  find  it  useful 
to  work  through  that  matrix  (either  manually  in  Table  6.1  or  using  the  Excel  tool 
described  below)  to  see  what  vulnerabilities  may  already  be  present  in  the  system  as 
a  result  of  the  security  techniques  employed. 

THE  RISK  ASSESSMENT  AND  MITIGATION  SELECTION  SPREADSHEET 

After  performing  the  first  three  steps,  the  methodology’s  complexity  increases 
greatly.  The  vulnerability  assessment  and  mitigation  selection  spreadsheet  shown  in 
Figure  7.1  reduces  this  complexity  by  providing  automated  lookups  and  calculations 
based  on  both  the  methodology  and  the  information  supplied  by  the  evaluator. 

Specifying  the  User  Type  and  Vulnerability  to  Be  Analyzed 

First,  the  evaluator  sets  up  the  basic  information  for  the  vulnerability  as  shown  in 
Figure  7.2.  The  evaluator’s  job  role  is  provided  at  part  1,  specifying  which  evaluator 
role  filter  to  employ  in  the  analysis  on  the  form.  A  free  text  box  is  included  at  part  2  to 
allow  the  user  to  describe  the  vulnerability  under  study  (i.e.,  copying  and 
embellishing  the  description  noted  on  the  vulnerability  form).  Parts  3  and  4  specify 
the  type  of  vulnerability  property  and  type  of  object  under  question  as  pull-down 
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Vulnerability  Attack  Rating  Form 
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0  Target  Vulnerability  (fill  in): 

Q  Target  Vulnerability  Attribute  Type  (select): 

r)  Target  Object  Type  (select): 
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Attack  Thread: 
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min(target,sum  all)  Negligible 
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Minimalists 
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Figure  7. 1 — The  VAM  Methodology  Spreadsheet  Tool 


Automating  and  Executing  the  Methodology:  A  Spreadsheet  Tool 


Object  type 


t4j  larget  Object  Type  (select): 
|  Physical 


RAND  MR1601-7.2 


Attack  Thread: 


AttackThread  Evaluation: 

0  Risk  (select):  O  Notes  (fill  In): 


Mitigation  Suggestions  to  Consider: 


(select  option  level): 


✓Selected  Mitigations  (fill  In): 


|  Negligible  |^1 

|  Negligible  |^| 

|  Negligible  |^~| 

|  Negligible  |^~| 

|  Negligible  |^1 


to  Adversary:  Deception  for 


Unmltlaated 

Score: 

Rating  Score 

(min  1st  3) 

Negligible  0 

Minimalists 

(min  all) 

Negligible  0 

Nation  States 

mln(target,  sum  1st  3) 

Negligible  0 

Minimalists 

min(target,sum  all) 

Negligible  0 

Nation  States 

(select  attack  step): 

|  Knowledge  |  ji~| 
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Figure  7.2 — Specifying  the  User  Type  and  Vulnerability  to  Be  Analyzed 
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Evaluating  the  Risks  for  Each  Attack  Component 

Second,  the  evaluator  needs  to  evaluate  the  risks  of  the  system  vulnerability  for  the 
five  attack  components — knowledge,  access,  target  vulnerability,  non-retribution, 
and  assess — by  completing  steps  5  through  7,  shown  in  Figure  7.3.  Nondeliberate 
failures  can  be  assessed  by  completing  only  the  target  vulnerability  row  with  the 
vulnerability  that  leads  to  the  failure  of  concern. 

Part  5  allows  the  evaluator  to  review  the  basic  ways  an  adversary  may  achieve  the 
four  supporting  attack  components  (knowledge,  access,  non-retribution,  and  assess) 
that  support  the  target  vulnerability  assessed  earlier  in  step  3.  Here  the  evaluator  can 
select  an  attack  component  in  the  pull-down  menu  and  view  the  methods  from 
Table  6.4  based  on  the  object  type  specified  in  part  4. 
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Figure  7.3 — Evaluating  the  Risks  for  Each  Attack  Component 
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Based  on  prior  reviews  and  part  5,  the  evaluator  rates  in  step  6  the  risks  for  each  of 
the  five  attack  components  using  pull-down  menus.  The  risks  are  rated  as  either 
negligible,  low,  moderate,  or  high. 

Based  on  these  ratings,  the  system  performs  four  simple  calculations  to  provide  a 
combined  risk  rating  and  score.  The  risk  rating  gives  a  simple  negligible,  low, 
moderate,  or  high  value  for  all  five  components  together,  while  the  score  is  a  numeric 
value  between  0  and  10.  The  tool  uses  four  simple  algorithms  to  combine  the  risk 
ratings. 

The  first  algorithm,  labeled  “min  1st  3,’’  uses  the  minimum  rating  from  the  key  three 
attack  components  (knowledge,  access,  and  target  vulnerability)  that  are  essential  to 
any  10 /IW  attack.  This  algorithm  takes  the  philosophy  of  rating  the  “weakest  link"  of 
the  essential  components  and  is  most  relevant  to  mitigation  strategies  that  try  to 
prevent  an  attack  by  denying  the  adversary  a  key  link  in  the  attack  (e.g.,  when  dealing 
with  minimalist  attackers  who  do  not  worry  as  much  about  non-retribution  or 
assessing  the  success  of  their  attack) . 

The  second  algorithm,  labeled  “min  all,”  also  uses  the  “weakest  link”  philosophy  but 
provides  the  minimum  rating  from  all  five  attack  components.  Thus,  this  value  is 
most  relevant  in  situations  in  which  the  adversary  is  concerned  with  all  five 
components  equally  (e.g.,  nation-states)  and  in  which  the  security  approach  is  to 
deny  the  attacker  all  these  links. 

The  third  algorithm,  labeled  “min(target,  sum  1st  3),”  calculates  a  combined  rating  of 
the  three  key  components  but  chooses  the  target  rating  if  it  is  less  than  that 
combined  sum.  This  algorithm  is  useful  when  the  evaluator,  in  dealing  with 
minimalist  attackers,  wants  to  combine  the  values  of  the  key  components  but  also 
recognizes  that  the  target  vulnerability  is  essential  (i.e.,  if  there  is  a  very  low  risk  to 
the  target  vulnerability,  no  amount  of  knowledge  or  access  will  improve  the  ultimate 
attackability  of  the  target). 

Finally  the  fourth  algorithm,  labeled  “min(target,  sum  all),”  combines  all  five  attack 
components  (i.e.,  for  nation-state  attacks)  but  also  recognizes  that  the  target 
vulnerability  has  to  be  there  for  an  attack. 

Other  algorithms  could,  of  course,  be  developed  to  combine  the  evaluator-supplied 
risk  ratings,  but  these  four  serve  as  reasonable  starting  points  in  trying  to  provide  an 
overall  rating  for  the  vulnerability  in  question.  The  use  of  the  “min”  function  reflects 
the  importance  of  each  component  to  an  information  attack  (sometimes  reflected  in 
the  saying  that  “10  is  a  three-legged  stool”),  and  the  resulting  important  security 
observation  that  even  though  a  user  may  not  be  able  to  address  a  vulnerability  in  one 
area  (say,  the  target  vulnerability  from  a  computer  design),  techniques  applied  in 
other  areas  (say,  denying  access  or  knowledge)  can  have  a  significant  positive  effect 
in  securing  a  system.  The  “sum”  function  can  also  be  useful  in  combining  mitigation 
effects  across  the  attack  components,  especially  when  complete  risk  mitigation  is  not 
possible  in  a  key  area. 
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Additional  use  of  these  score-combination  algorithms  is  needed  to  understand  their 
utility  and  validity  under  different  types  of  attack  weightings  and  approaches  for 
different  adversary  types.  Given  the  subjective  nature  of  the  ratings,  more- 
complicated  algorithms  may  be  meaningless  and  merely  make  it  harder  to 
understand  the  underlying  risks.  Under  certain  circumstances,  it  may  be  beneficial 
merely  to  compare  the  pre-  and  post-mitigated  ratings  input  by  the  user,  forgoing 
the  scoring  mechanism. 

Tool  users  will  note  that  the  system  provides  colorings  to  the  ratings  (clear,  yellow, 
orange,  and  red,  respectively)  to  improve  the  ability  to  skim  the  ratings  on  the 
spreadsheet  and  quickly  determine  how  a  given  vulnerability  rates  (especially  in 
comparison  to  ratings  for  other  vulnerabilities  on  separate  worksheets),  how 
effective  the  mitigation  strategies  are  anticipated  to  be,  and  what  attack  components 
will  receive  the  mitigation  focus. 


Considering  and  Selecting  Mitigations 

Third,  the  evaluator  uses  the  tool  to  review  and  select  mitigation  strategies  across  the 
attack  component  areas.  Figure  7.4  shows  the  part  of  the  spreadsheet  that  automates 
the  matrix  lookup,  matching  relevant  security  techniques  to  vulnerabilities  for  each 
attack  component  given  the  evaluator’s  role. 
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Figure  7.4 — Considering  and  Selecting  Mitigations 
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Part  8  allows  the  evaluator  to  review  the  mitigation  recommendations  for  each  of  the 
attack  components.  The  primary  or  secondary  recommendations  from  the  matrix  are 
shown  based  on  the  evaluator’s  selection  in  the  list  menu.  Relevant  techniques  are 
shown  in  the  five  attack  category  rows.  Examples  and  explanations  of  what  these 
techniques  entail  can  be  viewed  by  selecting  the  technique  in  the  pull-down  menu 
below  the  suggestion  list.  The  tool  also  looks  up  the  primary  and  secondary  cautions 
in  the  matrix  for  the  indicated  security  technique. 

Using  this  information,  the  evaluator  selects  the  best  mitigation  approaches  for  his 
or  her  particular  situation,  taking  into  account  the  cautions,  the  risk  profile  across 
the  attack  components,  the  available  techniques  across  that  profile,  the  implemen¬ 
tation  issues  (cost,  availability,  purview,  etc.),  and  the  potential  benefits.  Part  9  pro¬ 
vides  free  text  space  for  the  evaluator  to  record  the  security  techniques  he  or  she 
plans  to  implement. 

Rating  Costs  and  the  Mitigated  Risks 

Now  that  the  evaluator  has  selected  the  security  techniques  for  further  consideration 
and  implementation,  the  tool  allows  the  evaluator  to  record  his  or  her  rating  of  the 
cost,  difficulty,  and  purview  for  each  attack  component’s  mitigation  set  under  part  10 
in  Figure  7.5. 
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Figure  7.5 — Rating  Costs  and  the  Mitigated  Risks 
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This  figure  also  shows  part  11,  where  the  evaluator  can  estimate  what  the  risks 
should  be  for  each  component  of  the  attack  after  the  selected  security  techniques  are 
implemented.  The  mitigated  risk  estimates  use  the  same  format  as  the  unmitigated 
risk  rating  scheme,  employing  pull-down  menus  and  four  rating  values  (negligible, 
low,  moderate,  or  high).  The  tool  uses  the  same  algorithms  to  produce  combined  risk 
ratings  and  scores,  and  shows  again  the  unmitigated  ratings  and  scores  next  to  the 
new  ones  for  comparison. 

In  addition  to  helping  the  evaluator  work  through  estimates  and  decide  which 
security  techniques  to  pursue,  the  cost,  applicability,  and  risk  ratings  help  to  record 
these  assessments  for  future  review.  They  provide  a  visual  representation  of  the 
evaluator’s  expert  assessments  both  when  reviewing  the  security  techniques  under 
consideration  for  all  the  vulnerabilities  across  each  worksheet  completed  and  to 
provide  descriptions  and  overviews  to  managers  and  customers  for  approval  and 
funding  decisions. 

The  evaluator  can  also  use  parts  10  and  11  in  the  worksheet  to  record  the  results  of 
applying  and  testing  the  security  techniques  to  the  actual  system  (steps  5  and  6  of  the 
methodology).  These  results  are  much  more  definitive  than  the  evaluator’s  estimates 
during  step  4  and  are  important  to  record  both  to  reassess  what  additional 
procedures  should  be  taken  to  mitigate  the  identified  (i.e.,  a  repeat  of  steps  4-6)  and 
for  future  reference  in  rating  the  effect  of  security  techniques  in  reducing  risks. 


Chapter  Eight 

NEXT  STEPS  AND  DISCUSSION 


Here  we  present  some  deficiencies  in  the  current  VAM  methodology,  possible  next 
steps,  and  some  general  discussion  about  the  methodology,  its  use,  and  the  utility  of 
security  assessments. 

FUTURE  CHALLENGES  AND  OPPORTUNITIES 

While  the  VAM  methodology  advances  the  techniques  available  for  assessing  and 
mitigating  information  system  vulnerabilities,  the  entire  six-step  methodology  would 
benefit  from  additional  automation  development  and  support  aids. 

Guiding  the  Evaluation  of  Critical  Functions  and  Systems 

Applying  the  strategy-to-tasks  technique  to  reviewing  the  critical  information  func¬ 
tions  and  their  supporting  systems  (steps  1  and  2)  may  benefit  from  specific  guid¬ 
ance  and  worksheets  in  the  tool  to  help  the  evaluator  explore  what  is  most  critical 
and  to  help  prompt  an  objective  review  that  avoids  standard  concerns  and  prede¬ 
fined  notions.  These  steps  focus  on  the  essential  information  functions  and  the  sys¬ 
tems  essential  for  supporting  the  functions,  but  additional  thought  or  structure  may 
be  helpful  for  addressing  and  relating  the  so-called  valuable  functions  and  systems, 
as  well  as  the  essential  functions  and  systems. 

Additional  Guidance  and  Automation: 

Spreadsheet  and  Web-Based  Implementations 

While  the  current  spreadsheet  tool  greatly  assists  in  exercising  the  methodology 
(especially  steps  3  and  4),  the  use  of  a  Web-based  implementation  could  offer  a 
number  of  significant  advantages.  A  Web-based  version  could  be  structured  around  a 
question-and-answer  format,  in  which  the  system  helps  walk  the  evaluator  through 
the  entire  process.  The  system  could  also  help  the  evaluator  deal  with  the  complexity 
of  multiple  vulnerabilities  by  automatically  filling  in  subordinate  forms  with  prior 
data  and  settings.  An  online  database  could  also  facilitate  the  storage  and  preserva¬ 
tion  of  the  assessment  findings  and  eliminate  the  need  to  duplicate  worksheet  forms 
for  multiple  vulnerability  assessments.  Nevertheless,  the  spreadsheet  version  has 
proven  very  useful  in  our  early  application  of  the  methodology  to  Naval  systems,  and 
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we  anticipate  receiving  feedback  from  additional  users  who  have  shown  interest  in 
using  the  methodology. 

Prioritizing  Security  Options 

The  method  of  deciding  what  security  techniques  to  employ  and  how  well  they  cover 
the  vulnerability  space  can  also  benefit  from  additional  operational  mathematics.  An 
unpublished  approach  developed  by  Richard  Hillestad  and  colleagues  at  RAND  has 
been  used  as  a  complement  to  the  VAM  methodology  in  reviewing  RAND’s  own 
organizational  vulnerabilities,  generating  security  options,  and  prioritizing  these 
options  given  fiscal  constraints  and  the  organization’s  risk  tolerance.  We  anticipate 
that  this  integer  programming-based  approach  will  be  useful  to  other  organizations 
and  will  serve  an  important  complementary  role  with  the  VAM  methodology. 

Quantitative  Assessments  of  Threats,  Risks,  and  Mitigations 

Quantitative  assessments  and  valuations  of  threats,  risks,  and  mitigations  remain  a 
challenge.  The  simple  assessments  currently  used  in  the  methodology  rely  on  the 
subjective  expertise  of  the  evaluator  and  do  not  provide  an  independent  way  to  gen¬ 
erate  quantitative  (or  even  qualitative)  values.  This  problem  is  exacerbated  in  the 
areas  where  the  VAM  methodology  shines:  when  the  threats  are  theoretical  and  when 
vulnerabilities  have  yet  to  be  exploited  by  adversaries.  If  there  is  no  history  of  attacks, 
then  it  is  hard  to 

•  estimate  a  probability  that  the  vulnerability  will  be  exploited, 

•  perform  a  cost-benefit  analysis  for  security  investments  against  that  threat,  or 

•  conduct  tradeoff  analysis  between  various  theoretical  threats  and  vulnerabilities. 

This  problem  was  poignantly  demonstrated  in  the  difficulties  of  justifying  counter¬ 
terrorism  funding  before  the  attacks  of  September  11,  2001,  and  in  calculating  the 
probability  and  severity  of  anthrax  attacks  before  the  anthrax  mailings  in  2002. 
However,  September  1 1  and  the  anthrax  mailings  demonstrated  the  importance  of 
finding  and  mitigating  previously  unexploited  vulnerabilities  and  continuing  to  look 
for  the  next  vulnerability  that  an  adversary  may  turn  to  once  one  addresses  a 
previously  exploited  vulnerability.  We  need  to  be  proactive  in  addition  to  reactive. 

Integrating  VAM  Functions  into  Other  Assessment  Methodologies 

Given  that  many  security  assessment  methodologies  share  very  similar  steps  with  the 
VAM  methodology’s  six  steps  and  the  fact  that  many  of  these  methodologies  lack  the 
depth  of  VAM’s  assessment  and  mitigation  suggestion,  it  may  be  useful  to  use  the 
core  of  VAM  (steps  3  and  4)  during  the  execution  of  these  other  established  method¬ 
ologies  and/or  formally  integrating  VAM’s  core  vulnerabilities,  matrix,  filtering,  and 
supporting  information  into  these  methods. 
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Using  VAM  to  Guide  Information  Attacks 

The  primary  focus  of  the  methodology  to  date  has  been  in  information  system  pro¬ 
tection,  but  the  broader  review  of  vulnerability  fundamentals  and  attack  stages  could 
be  useful  in  understanding  10 /IW.  A  comprehensive  review  of  what  a  defender  may 
do  before,  during,  or  after  an  attack  in  response  to  our  own  attack  can  also  help  us  to 
design  more  effective  10  tools,  methods,  and  procedures  while  minimizing  our  expo¬ 
sure. 

Applications  of  VAM  Beyond  Information  Systems 

In  addition,  the  explicit  handling  of  physical,  human/social,  and  infrastructure  sys¬ 
tems  raises  the  possibility  that  the  methodology  may  be  useful  in  assessing  and  miti¬ 
gating  vulnerabilities  in  systems  other  than  information  systems.  Many  types  of  sys¬ 
tems  that  are  critical  to  social  functions  (e.g.,  financial,  power,  transportation,  agri¬ 
cultural,  water,  medical,  law  enforcement,  governance)  rely  on  physical,  human/ 
social,  and  infrastructure  objects  and  include  growing  dependence  on  cyber  compo¬ 
nents.  RAND  has  not  yet  explored  the  issues  in  expanding  the  application  of  the 
methodology  to  these  domains,  but  these  opportunities  seem  promising.  The  list  of 
vulnerability  properties  and  number  of  critical  attack  components  may  need  to  be 
expanded  in  some  of  these  domains  (e.g.,  in  the  biological  domain),  but  many  of  the 
fundamental  properties  and  attack  stages  will  likely  be  applicable  and  useful  to  con¬ 
sider. 

WHAT  VULNERABILITY  WILL  FAIL  OR  BE  ATTACKED  NEXT? 

One  of  the  methodology’s  strong  points  is  the  ability  to  help  the  evaluator  think  “out 
of  the  box”  and  look  for  new  vulnerabilities  that  have  yet  to  cause  system  failures  or 
be  exploited  by  attackers.  This  kind  of  review  can  be  quite  important  when  the  sys¬ 
tem  is  complex  or  the  adversary  is  creative  and  adaptive  to  the  security  responses 
and  postures  used  by  the  defender.  For  example,  robustness  through  redundancy  or 
performance  monitoring  can  be  important  as  organizations  come  to  rely  more  on 
complex  information  systems.  Also,  terrorist  organizations  tend  to  look  for  simple  yet 
easy  vulnerabilities  to  exploit,  while  current  security  procedures  often  focus  on  solv¬ 
ing  yesterday’s  exploited  vulnerability. 

USABILITY  ISSUES 

Note  that  even  if  the  evaluator  cannot  directly  fix  a  vulnerability  by  implementing  the 
security  techniques,  the  assessment  can  nevertheless  be  useful  in  providing  a  com¬ 
prehensive  justification  and  explanation  of  the  vulnerability  to  other  individuals  who 
do  have  the  responsibility  and  authority  to  implement  remedies  to  the  vulnerability. 
Such  assessments  and  justifications  can  be  quite  important  in  informing  others  of 
the  security  needs  and  providing  a  basis  for  management  budgeting  and  decision¬ 
making. 
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Note  also  that  little  discussion  has  been  included  here  on  how  to  implement  specific 
security  techniques  or  on  testing  the  effectiveness  of  the  security  techniques.  Such 
testing  as  red  teaming  and  actual  attack  exercises  can  be  difficult  to  accomplish. 
Oftentimes,  an  organization  is  too  busy  conducting  operations  to  run  an  exercise 
that  can  take  down  its  critical  information  systems.  INFOCONs,  for  example,  are 
usually  simulated  during  attack  exercises,  and  aggressive  red  teaming  is  rarely  con¬ 
ducted  against  real  operational  systems.  Also,  standard  certification  for  military 
deployments  (e.g.,  inspections,  certifications,  assessments,  and  visits  [ICAV],  such  as 
a  Computer  Network  Vulnerability  Assessment)  runs  through  bottom-up  vulnerabil¬ 
ities  (patches,  alerts,  viruses,  etc.)  with  little  creative  red  teaming.  Anderson  et  al. 
(1999)  includes  additional  thoughts  on  steps  5  and  6. 

WHY  PERFORM  SECURITY  ASSESSMENTS? 

Performing  a  security  assessment  can  require  significant  investment  in  time  and 
resources,  but  you  get  what  you  pay  for.  These  investments  might  be  viewed  by  some 
as  unnecessary,  since  many  vulnerabilities  are  known  and  because  limited  resources 
may  already  prevent  the  implementation  of  security  responses  to  the  vulnerabilities. 
Thus,  many  may  not  see  a  market  for  comprehensive  assessments  or  for  discovering 
vulnerabilities  that  have  not  yet  been  exploited  by  adversaries. 

This  position  is  shortsighted.  A  careful,  objective  review  of  security  problems  can 
help  justify  additional  expenditures.  The  execution  of  a  methodology  like  VAM  links 
security  investments  to  vulnerabilities  to  critical  information  functions,  allowing 
management  to  better  understand  the  operational  significance  of  vulnerabilities. 
Thus,  the  justifications  for  resource  requests  are  expressed  in  the  proper  language 
and  level  of  functional  effects  rather  than  as  mere  wish  lists  with  indeterminate 
effects  on  the  core  functions  of  an  organization. 

Also,  executing  a  methodology  can  help  to  balance  limited  resources,  ensuring  that 
the  most  important  vulnerabilities  are  fixed  first  and  that  alternative  security  tech¬ 
niques  with  better  cost-benefit  ratios  are  not  overlooked. 


Chapter  Nine 

SUMMARY  AND  CONCLUSIONS 


VAM  fills  a  gap  in  existing  methodologies  by  providing  explicit  guidance  on  finding 
system  vulnerabilities  and  by  suggesting  relevant  mitigations.  The  VAM  methodology 
provides  a  comprehensive,  top-down  approach  to  information  system  security, 
combining  a  novel  assessment  and  recommendation-generating  matrix  with  filtering 
approaches  to  refine  the  security  options  under  consideration. 

The  methodology  helps  to  identify  new  types  of  vulnerabilities  as  well  as  known 
types  of  vulnerabilities  in  one’s  information  systems.  Thus,  the  methodology  takes  a 
comprehensive  approach  to  understanding  vulnerabilities  and  does  not  rely  on 
canned  scanning  tools  or  checklists  (however  valuable)  for  the  sole  identifier  of  vul¬ 
nerabilities  of  concern. 

The  vulnerabilities  and  security  taxonomies  in  the  methodology  are  fairly  complete. 
Viewing  vulnerability  properties  separate  from  system  objects  has  proved  a  valuable 
way  of  reviewing  the  system  for  vulnerabilities,  since  the  properties  often  apply  to 
each  type  of  object.  Also,  each  object  type  plays  important  roles  in  information  sys¬ 
tems.  The  realization  and  expansion  of  the  vulnerability  review  to  explicitly  consider 
physical,  human/social,  and  infrastructure  objects  in  addition  to  cyber  and  com¬ 
puter  hardware  objects  recognize  and  accommodate  the  importance  of  all  these 
aspects  to  the  proper  functioning  of  information  systems. 

Providing  a  computerized  aid  that  executes  the  methodology  during  an  evaluation 
greatly  improved  the  usability  of  the  methodology,  especially  given  that  the  current 
approach  generates  many  more  suggestions  than  the  earlier  version  by  Anderson  et 
al.  (1999). 

The  current  spreadsheet  implementation  in  Excel  has  the  benefit  of  being  usable  by 
the  large  number  of  personal  computer  users  that  already  have  the  Excel  program  on 
their  machines.  The  spreadsheet  also  gives  the  user  flexibility  to  generate  analysis 
reports  and  even  input  custom  rating  algorithms  to  accommodate  local  needs  and 
situations. 

The  methodology  can  be  used  to  improve  security  both  during  system  design  stages 
and  during  operation.  The  methodology  also  identifies  steps  that  policymakers  can 
make  to  improve  information  system  security. 
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The  methodology  should  be  useful  for  individuals  and  teams.  Individuals  can  focus 
on  their  individual  situation  and  areas  of  responsibility,  while  teams  can  bring  mul¬ 
tiple  expertises  to  bear  on  the  analyses  as  well  as  perspectives  on  different  divisions 
within  an  organization.  The  methodology  could  also  be  used  in  parallel  by  different 
divisions  to  focus  on  their  own  vulnerabilities,  integrating  them  later  at  a  high-level 
review  once  each  group’s  needs  and  justifications  are  understood.  While  the  VAM 
methodology  has  proven  its  worth  in  separate  studies  of  real  information  systems, 
the  current  methodology  would  benefit  from  additional  development  of  guidance  for 
steps  1  and  2  and  tool  automation  refinement.  Integration  with  identified  techniques 
that  aid  in  the  analysis  of  risks  and  the  cost-effectiveness  of  security  options  would 
be  useful  and  is  being  pursued. 

We  also  believe  that  the  general  approach  of  the  methodology,  as  well  as  a  significant 
portion  of  the  vulnerability  attributes,  could  be  extended  to  other  systems  whose 
primary  role  is  not  information  processing.  We  are  also  exploring  these  possibilities. 


Appendix 

VULNERABILITY  TO  MITIGATION  MAP  VALUES 


The  core  of  our  methodology  is  the  matrix  of  values  that  maps  vulnerability  attri¬ 
butes  to  the  security  techniques  that  can  mitigate  these  vulnerabilities  (Table  6.1).  In 
the  tables  below  we  list  and  explain  why  certain  techniques  can  be  useful  in  mitigat¬ 
ing  each  vulnerability  attribute.  We  also  call  attention  to  instances  in  which  certain 
mitigation  techniques  can  incur  vulnerabilities. 

Each  table  lists  the  security  techniques  that  appear  most  relevant  for  the  table’s  vul¬ 
nerability  attribute.  The  security  techniques  are  listed  in  the  left  columns  and 
descriptions  of  why  each  security  technique  was  deemed  relevant  is  listed  in  the  right 
columns.  Furthermore,  the  security  techniques  are  grouped  according  to  whether 
they  were  judged  to  be  of  primary  and  common  importance  in  helping  to  mitigate 
the  vulnerability  attribute,  or  of  secondary  and  less  common  importance.  As 
described  in  Chapter  Six,  primary  techniques  are  identified  with  a  numeral  2  in  Table 
6.1,  and  secondary  techniques  are  identified  with  a  numeral  1.  Some  tables  here  also 
contain  security  techniques  that  can  be  facilitated  by  the  table’s  vulnerability.  When 
present,  these  techniques  are  listed  in  the  last  rows  and  are  identified  with  a  numeral 
Oin  Table  6.1. 

So,  for  example,  Table  A.l  lists  Heterogeneity  as  a  primary  mitigation  technique  for 
the  Singularity  vulnerability  attribute,  and  Centralization  as  a  secondary  technique. 
Table  6.1,  therefore,  has  a  2  at  the  intersection  of  the  Singularity  attribute  and  the 
technique  Heterogeneity,  and  a  1  at  the  intersection  of  the  Singularity  attribute  and 
the  technique  Centralization.  No  security  techniques  are  identified  as  being  facili¬ 
tated  by  singularities.  Table  A.3,  however,  identifies  four  security  techniques 
(Centralization,  Adaptability  and  Learning,  Deception  for  ISR,  and  Law  Enforcement 
and  Civil  Proceedings)  that  are  facilitated  by  the  Centrality  vulnerability  attribute. 
Each  techniques  has  a  0  in  the  Centrality  row  in  Table  6.1. 
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MITIGATION  TECHNIQUES  THAT  ADDRESS  OR  ARE  FACILITATED 
BY  VULNERABILITIES 


Table  A.  1 

Mitigation  Techniques  That  Address  Singularity 


Primary 

Fleterogeneity 

Redundancy 

Decentralization 

W&A,  Software/FIardware 
Engineering,  Evaluations, 
Testing 

Control  of  Exposure, 
Access,  and  Output 

Flardening 

Fault,  Uncertainty,  Validity, 
and  Quality  Tolerance 
and  Graceful  Degradation 

Threat  Response  Structures 
and  Plans 

Rapid  Reconstitution  and 
Recovery 

Adaptability  and  Learning 


Secondary 
Centralization 
Trust  Learning  and 
Enforcement  Systems 
N  on-Repudiation 

Static  Resource  Allocation 

Dynamic  Resource 
Allocation 

General  Management 

Intelligence  Operations 
Self-Awareness, 

Monitoring,  and 
Assessments 
General 

Counterintelligence 
Unpredictable  to  Adversary 
Deception  for  Cl 
Denial  of  ISR  and  Target 
Acquisition 


Heterogeneity  provides  alternatives  to  the  singular  item  or  system. 

Redundant  systems  can  provide  a  more  robust  capacity. 

Decentralization  can  introduce  redundancy  directly  or  disperse 
singularities,  making  them  harder  to  target. 

Engineering,  W&A,  evaluations,  and  testing  can  make  singular 
components  more  robust. 

Control  of  exposure,  access,  and  output  can  directly  protect  the 
singularity. 

Hardening  can  directly  protect  a  singularity  and  make  it  more  difficult  to 
damage. 

Singular  components  that  can  operate  under  faults  and  difficult 
conditions  are  less  likely  to  fail. 

Many  response  plans  introduce  backups  and  contingencies  that  work 
around  singularities. 

Rapid  recovery  can  reduce  the  effects  of  losing  a  singular  component. 

This  provides  learning  or  adaptation  materials  and  plans  to  allow  others 
to  rapidly  fill  singularities. 


Centralized  control  can  help  manage  access  to  and  protect  a  singularity. 

Trust  systems  can  be  particularly  important  for  singular  systems  to  help 
control  access  and  exposure. 

Non-repudiation  can  be  particularly  important  for  singular  systems  to 
provide  deterrence  and  evidence  of  untrustworthy  behavior. 

Static  resource  allocations  can  help  to  work  around  and  prevent 
overtaxing  singularities. 

Dynamic  resource  allocations  can  help  to  work  around  and  prevent 
overtaxing  singularities. 

Proper  management  procedures,  such  as  quality  control,  training,  general 
security,  and  procedural  control,  can  help  to  protect  singularities. 

Intelligence  can  identify  which  singularities  our  adversaries  know  about. 

Self-assessments  can  identify  singularities. 


Cl  can  prevent  adversaries  from  knowing  about  vulnerable  singularities. 

Cl  can  prevent  adversaries  from  knowing  about  vulnerable  singularities. 
Deceptions  can  hide  singularities. 

ISR  denials  can  hide  singularities. 
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Table  A.2 

Mitigation  Techniques  That  Address  Uniqueness 


Primary 

Heterogeneity 

Redundancy 

W&A,  Software/Hardware 
Engineering,  Evaluations, 
Testing 

Control  of  Exposure, 

Access,  and  Output 
Hardening 

Fault,  Uncertainty,  Validity, 
and  Quality  Tolerance 
and  Graceful  Degradation 
Threat  Response  Structures 
and  Plans 

Rapid  Reconstitution  and 
Recovery 

Secondary 

Centralization 

Decentralization 

Static  Resource  Allocation 

Dynamic  Resource 
Allocation 

General  Management 

Intelligence  Operations 

Self-Awareness, 

Monitoring,  and 
Assessments 
General  Cl 

Unpredictable  to  Adversary 

Deception  for  Cl 
Denial  of  ISR  and  Target 
Acquisition 
Criminal  and  Legal 
Penalties  and  Guarantees 


Heterogeneity  provides  alternatives  to  the  unique  item  or  system. 

Redundant  systems  (even  if  of  the  same  unique  type)  can  provide 
backups  or  parts  during  failure  of  a  unique  system. 

Engineering,  W&A,  evaluations,  and  testing  can  make  unique 
components  more  robust. 

Control  of  exposure,  access,  and  output  can  directly  protect  the  unique 
component. 

Hardening  can  directly  protect  a  unique  system  and  make  it  more  difficult 
to  damage. 

Unique  components  that  can  operate  under  faults  and  difficult 
conditions  are  less  likely  to  fail. 

Many  response  plans  introduce  backups  and  contingencies  that  provide 
new  alternatives  to  unique  items. 

Rapid  recovery  can  reduce  the  effects  of  losing  a  unique  component. 


A  unique  item  at  a  central  location  could  be  monitored,  maintained,  and 
repaired  more  effectively. 

Decentralization  can  introduce  redundancy  directly  or  disperse  unique 
systems,  making  them  harder  to  target. 

Static  resource  allocations  can  help  to  work  around  and  prevent 
overtaxing  unique  systems. 

Dynamic  resource  allocations  can  help  to  work  around  and  prevent 
overtaxing  unique  systems. 

Proper  management  procedures,  such  as  quality  control,  training,  general 
security,  and  procedural  control,  can  help  to  protect  unique  systems. 

Intelligence  can  identify  which  unique  components  our  adversaries  know 
about. 

Self-assessments  can  identify  uniqueness  in  our  systems. 


Cl  can  prevent  adversaries  from  knowing  about  unique,  vulnerable 
components. 

Cl  can  prevent  adversaries  from  knowing  about  unique,  vulnerable 
components. 

Deceptions  can  hide  the  uniqueness  of  components. 

ISR  denials  can  hide  the  uniqueness  of  components. 

Warrantees  and  guarantees  serve  as  useful  ways  to  certify  the  capabilities 
and  stability  of  unique  items  and  can  provide  (often  longer-term) 
remedies  for  failures. 


88  Finding  and  Fixing  Vulnerabilities  in  Information  Systems:  VAM  Methodology 


Table  A.3 

Mitigation  Techniques  That  Address  or  Are  Facilitated  by  Centrality 


Primary 

Decentralization 

W&A,  Software/FIardware 
Engineering,  Evaluations, 
Testing 

Control  of  Exposure, 
Access,  and  Output 

Flardening 

Fault,  Uncertainty,  Validity, 
and  Quality  Tolerance 
and  Graceful  Degradation 

Threat  Response  Structures 
and  Plans 

Preventive  and  Retributive 
Information/  Military 
Operations 

Secondary 

Fleterogeneity 

Redundancy 

Trust  Learning  and 
Enforcement  Systems 

N  on-Repudiation 

General  Management 


Rapid  Reconstitution  and 
Recovery 

Immunological  Defense 
Systems 

Intelligence  Operations 
Self-Awareness, 

Monitoring,  and 
Assessments 
General  Cl 

Unpredictable  to  Adversary 

Deception  for  Cl 
Denial  of  ISR  and  Target 
Acquisition 


Decentralization  directly  addresses  centrality  concerns. 

Engineering,  W&A,  evaluations,  and  testing  can  make  centralized 
systems  more  robust. 

Control  of  exposure,  access,  and  output  can  directly  protect  centralized 
components. 

Hardening  can  directly  protect  a  centralized  system  and  make  it  more 
difficult  to  damage. 

Centralized  systems  that  can  operate  under  faults  and  difficult  conditions 
are  less  likely  to  fail. 

Many  response  plans  develop  ways  to  protect  and  back  up  centralized 
capabilities. 

Centralized  facilities  are  often  higher-value  targets  for  adversaries,  thus 
warranting  a  strong  and  aggressive  response  if  damaged. 


Heterogeneity  reduces  the  variety  of  systems  that  would  have  to  be 
compromised,  even  if  they  are  still  maintained  at  a  central  site. 

Even  if  centralized,  redundant  systems  can  provide  more-robust 
capability. 

Trust  systems  can  be  particularly  important  for  centralized  systems  to 
help  control  access  and  exposure. 

Non-repudiation  can  be  particularly  important  for  centralized  systems  to 
provide  deterrence  and  evidence  of  untrustworthy  behavior. 

Proper  management  procedures,  such  as  quality  control,  training,  general 
security,  and  procedural  control,  can  help  to  protect  centralized 
systems. 

Rapid  recovery  can  reduce  the  effects  of  losing  the  centralized 
components  and  can  in  fact  be  facilitated  by  centrality. 

The  ability  of  these  systems  to  share  information  with  decentralized 
nodes  can  mitigate  the  reason(s)  for  centrality. 

Intelligence  can  identify  which  singularities  our  adversaries  know  about. 

Self-assessments  can  characterize  the  scope  of  our  dependence  on 
centralized  systems. 

Cl  can  prevent  adversaries  from  locating  and  characterizing  our 
centralities. 

Cl  can  prevent  adversaries  from  locating  and  characterizing  our 
centralities. 

Deceptions  can  hide  the  centrality  of  a  system. 

ISR  details  can  hide  the  centrality  of  a  system. 
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Table  A.3 — Continued 


Facilitated  by  Centrality 
Centralization 

Adaptability  and  Learning 


Deception  for  ISR 
Law  Enforcement;  Civil 
Proceedings 


Leverage  centrality  to  maximum  advantage  (e.g.,  quality  control, 
consistency). 

Centrality  can  facilitate  learning  and  adaptation  through  improved  self- 
awareness  and  feedback.  Dissemination  of  lessons  learned  is  also 
facilitated  by  centrality. 

Centrality  could  enable  and  coordinate  deception  to  improve  ISR. 

Centralized  items  are  often  easier  for  law  enforcement  to  protect. 


Table  A.4 

Mitigation  Techniques  That  Address  or  Are  Facilitated  by  Homogeneity 


Primary 

Heterogeneity 

W&A,  Software/Hardware 
Engineering,  Evaluations, 
Testing 

Hardening 

Fault,  Uncertainty,  Validity, 
and  Quality  Tolerance 
and  Graceful  Degradation 

Secondary 

Redundancy 

Decentralization 

Control  of  Exposure, 

Access,  and  Output 

General  Management 


Self-Awareness, 

Monitoring,  and 
Assessments 
General  Cl 

Unpredictable  to  Adversary 

Deception  for  Cl 
Denial  of  ISR  and  Target 
Acquisition 

Facilitated  by  Homogeneity 

Static  Resource  Allocation 
Dynamic  Resource 
Allocation 

General  Management 


Heterogeneity  is  the  opposite  of  homogeneity,  introducing  a  range  of 
different  alternative  systems. 

Engineering,  W&A,  evaluations,  and  testing  can  be  more  extensive  on 
homogeneous  systems  and  make  them  more  robust  than  heterogeneous 
systems. 

Hardening  a  homogeneous  system  can  make  it  less  vulnerable  to  attack. 

Homogeneous  systems  that  can  operate  under  faults  and  difficult 
conditions  are  less  likely  to  fail  in  general. 


While  not  reducing  the  homogeneity,  redundant  items  can  make  those 
systems  more  robust  and  able  to  withstand  failures. 

Dispersal  of  homogeneous  targets  makes  them  harder  to  attack  all  at 
once. 

Control  of  exposure,  access,  and  output  can  directly  protect 
homogeneous  components.  Homogeneous  systems  can  facilitate 
control  design. 

Proper  management  procedures,  such  as  quality  control,  training,  general 
security,  and  procedural  control,  can  help  to  protect  homogeneous 
systems.  Note  that  homogeneous  systems  can  help  facilitate 
management  of  information  systems. 

Self-assessments  can  determine  how  heterogeneous  our  systems  have 
become. 

Cl  can  prevent  adversaries  from  understanding  what  systems  we  have 
standardized  on. 

Cl  can  prevent  adversaries  from  understanding  what  systems  we  have 
standardized  on. 

False  heterogeneity  can  hide  reliance  on  homogeneous  components. 

ISR  denials  can  prevent  adversaries  from  understanding  what  systems  we 
have  standardized  on. 


Note  that  homogeneous  systems  can  facilitate  resource  allocations. 

Note  that  homogeneous  systems  can  facilitate  resource  allocations. 

Proper  management  procedures,  such  as  quality  control,  training,  general 
security,  and  procedural  control,  can  help  to  protect  homogeneous 
systems.  Note  that  homogeneous  systems  can  help  facilitate 
management  of  information  systems. 
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Table  A.4 — Continued 


Rapid  Reconstitution  and 
Recovery 

Immunological  Defense 
Systems 
Vaccination 


Flomogeneity  can  facilitate  reconstitution  and  recovery  due  to  the 
availability  of  alternative  systems  and  parts  as  well  as  common  training 
and  knowledge  about  those  components. 

Flomogeneity  can  make  it  easier  to  apply  lessons  learned  from  other 
nodes. 

Flomogeneity  can  make  it  easier  to  apply  lessons  learned  from  other 
nodes. 


Table  A.5 

Mitigation  Techniques  That  Address  or  Are  Facilitated  by  Separability 


Primary 

Centralization 
W&A,  Software/Flardware 
Engineering,  Evaluations, 
Testing 

Fault,  Uncertainty,  Validity, 
and  Quality  Tolerance 
and  Graceful  Degradation 
General  Management 

Self-Awareness, 

Monitoring,  and 
Assessments 

Secondary 

Control  of  Exposure, 

Access,  and  Output 
Trust  Learning  and 
Enforcement  Systems 
Flardening 

Adaptability  and  Learning 

Immunological  Defense 
Systems 

Vaccination 

Intelligence  Operations 

General  Cl 

Unpredictable  to  Adversary 

Deception  for  Cl 

Denial  of  ISR  and  Target 
Acquisition 

Facilitated  by  Separability 

Deception  for  ISR 


Centralized  systems  will  be  harder  to  separate. 

Engineering,  W&A,  evaluations,  and  testing  can  look  for  ways  that  system 
components  can  be  isolated  and  develop  ways  to  reduce  this 
vulnerability. 

Systems  that  can  operate  despite  degraded  conditions  and  uncertainty 
are  harder  to  partition. 

Proper  management  and  coordination  can  help  ensure  cohesion  and 
communication. 

Monitoring  can  determine  breaks  in  system  interfaces,  facilitating  their 
restoration.  Assessments  can  identify  how  separations  have  happened 
in  the  past,  informing  corrective  measures. 


Control  of  exposure,  access,  and  output  can  protect  against  separability. 

Trust  systems  can  inform  interface  controllers  and  reduce  the  likelihood 
of  deceptive  separations. 

Flardening  system  interfaces  can  make  them  more  difficult  to  break. 

Adaptation  could  help  to  learn  and  recognize  attempts  to  partition  the 
system. 

Information  sharing  can  preclude  the  need  to  isolate  systems  under 
attack  and  share  information  about  such  attacks  and  how  to  defend 
against  them. 

Simulated  attacks  could  uncover  separability  risks  and  force  mitigation 
evaluations. 

Information  about  attacks  can  speed  efforts  to  reconnect  components 
and  tune  our  own  partitioning  activities. 

Cl  can  reduce  an  adversary’s  understanding  of  how  to  separate  system 
components. 

Cl  can  reduce  an  adversary’s  understanding  of  how  to  separate  system 
components. 

Deceptions  can  make  it  harder  to  know  how  to  separate  system 
components. 

ISR  denials  can  reduce  an  adversary’s  understanding  of  howto  separate 
system  components. 


Known  separabilities  can  be  used  in  our  deceptions  to  determine 
adversary’s  general  knowledge,  capabilities,  and  specific  knowledge 
about  us. 
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Table  A.6 

Mitigation  Techniques  That  Address  Logic  or  Implementation  Errors,  Fallibility 


Primary 

Heterogeneity 

W&A,  Software/Hardware 
Engineering,  Evaluations, 
Testing 

Control  of  Exposure, 

Access,  and  Output 
Hardening 

Fault,  Uncertainty,  Validity, 
and  Quality  Tolerance 
and  Graceful  Degradation 
General  Management 

Adaptability  and  Learning 
Immunological  Defense 
Systems 
Vaccination 
Secondary 
Centralization 

Decentralization 

Trust  Learning  and 
Enforcement  Systems 
Static  Resource  Allocation 
Dynamic  Resource 
Allocation 

Threat  Response  Structures 
and  Plans 

Rapid  Reconstitution  and 
Recovery 
Self-Awareness, 

Monitoring,  and 
Assessments 
General  Cl 

Unpredictable  to  Adversary 

Deception  for  Cl 

Denial  of  ISR  and  Target 
Acquisition 
Criminal  and  Legal 
Penalties  and  Guarantees 
Law  Enforcement;  Civil 
Proceedings 


A  variety  of  systems  can  complement  each  other  if  the  systems  have 
different  failure  conditions. 

Engineering,  W&A,  evaluations,  and  testing  can  identify  errors  and 
fallibilities  while  recommending  solutions. 

Exposure,  access,  and  output  controls  can  be  used  to  isolate  the  rest  of  the 
system  from  component  errors  and  fallibilities. 

Hardening  can  remove  errors  and  make  it  less  fallible. 

Tolerant  systems  are  able  to  handle  errors  better  when  they  happen. 


Management  reviews  and  quality  control  can  help  to  recognize  and  avoid 
errors  and  fallibilities. 

Examination  of  performance  can  help  to  locate  errors  and  adjust  to  them. 
Some  systems  automatically  recognize,  update,  patch,  or  correct  errors. 

Vaccination  uncovers  and  repairs  errors  directly. 


Flawed  systems  will  be  easier  to  manage,  control,  and  repair  if  they  are  at 
a  central  location. 

It  can  be  harder  to  understand  and  exploit  the  errors  in  systems  when 
they  are  dispersed. 

Trust  learning  can  reduce  fallibilities  due  to  excessive  accesses  and 
reasoning  about  protections. 

Resource  allocations  can  work  around  errors  and  failures. 

Resource  allocations  can  work  around  errors  and  failures. 

Many  response  plans  introduce  backups  and  contingencies  that  reduce 
fallibilities  or  minimize  the  effects  of  errors. 

A  rapid  recovery  capability  reduces  (but  usually  does  not  eliminate)  the 
effect  of  component  losses  and  errors. 

Monitoring  and  assessments  can  look  for  errors  and  fallibilities. 


Cl  can  reduce  an  adversary’s  understanding  of  system  errors  and 
fallibilities. 

Cl  can  reduce  an  adversary’s  understanding  of  system  errors  and 
fallibilities. 

Deceptions  can  reduce  an  adversary’s  understanding  of  system  errors  and 
fallibilities. 

ISR  details  can  reduce  an  adversary’s  understanding  of  system  errors  and 
fallibilities. 

Warrantees  and  bonding  can  provide  remediation  for  failed  systems  and 
motivate  manufacturers  to  eliminate  problems  in  the  first  place. 

Warrantees  and  bonding  can  provide  remediation  for  failed  systems. 
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Table  A.7 

Mitigation  Techniques  That  Address  or  Are  Facilitated  by  Design  Sensitivity, 
Fragility,  Limits,  or  Finiteness 


Primary 

Fleterogeneity 

Redundancy 

Decentralization 


W&A,  Software/Flardware 
Engineering,  Evaluations, 
Testing 

Control  of  Exposure, 

Access,  and  Output 

Flardening 

Fault,  Uncertainty,  Validity, 
and  Quality  Tolerance 
and  Graceful  Degradation 

Static  Resource  Allocation 

Dynamic  Resource 
Allocation 

General  Management 

Self-Awareness, 

Monitoring,  and 
Assessments 

Secondary 

Centralization 

Threat  Response  Structures 
and  Plans 

Rapid  Reconstitution  and 
Recovery 

Adaptability  and  Learning 

Immunological  Defense 
Systems 

Vaccination 

Intelligence  Operations 

Attack  Detection, 
Recognition,  Damage 
Assessment,  and 
Forensics  (Self  and  Foe) 

General  Cl 

Unpredictable  to  Adversary 


A  variety  of  systems  can  complement  each  other  if  they  have  different 
sensitivities,  fragilities,  operating  ranges,  or  limit  dimensions. 

Redundant  systems  can  provide  fallback  capability  or  help  spread  the 
processing  load  if  limits  are  reached. 

It  can  be  harder  to  understand  and  exploit  the  fragilities  and  limits  in 
systems  when  they  are  dispersed.  Decentralization  can  also  introduce 
improved  capacity  that  might  be  exploited  if  information  processing  can 
be  partitioned.  Dispersed  systems  can  also  be  used  as  alternative 
capacity  when  local  limits  are  reached. 

Engineering,  W&A,  evaluations,  and  testing  can  identify  and  resolve 
sensitivities,  fragilities,  and  limits. 

Controls  can  help  to  protect  fragile  systems  from  harsh  environments  or 
overloading  attacks. 

Flardening  can  make  the  design  less  fragile. 

Tolerant  systems  are  able  to  handle  fragilities,  sensitivities,  and  limits 
better  when  they  happen. 

Resource  allocations  can  balance  loads  to  prevent  failures  and  partition 
work  to  avoid  sensitivities. 

Resource  allocations  can  balance  loads  to  prevent  failures  and  partition 
work  to  avoid  sensitivities. 

Attentive  management  can  avoid  overloading  systems  and  stressing 
fragile  components. 

Status  monitoring  can  help  management  prevent  the  system  from 
crossing  limits,  avoid  sensitivities,  etc.  Assessments  can  continue  to 
identify  unknown  fragilities  and  limits. 


Fragile  and  limited  systems  will  be  easier  to  control  their  loads  and  inputs 
if  centralized. 

Response  plans  can  provide  additional  resources  to  minimize  limits  and 
the  effects  of  design  sensitivities  if  they  are  known. 

A  rapid  recovery  capability  reduces  (but  usually  does  not  eliminate)  the 
effect  of  component  losses  due  to  fragility  and  crossing  limitations. 

Examination  of  performance  can  help  to  locate  fragilities  and  limits  while 
developing  work-arounds. 

Some  systems  automatically  alert,  fuse,  recognize,  update,  patch,  and 
correct  sensitivities. 

Vaccination  uncovers  fragilities  and  limits  directly.  Some  may  be 
corrected  directly,  while  others  could  be  avoided  in  the  future. 

Information  on  attacks  that  target  limitations  and  sensitivities  can  be 
used  to  plan  and  implement  countermeasures. 

Behavior  and  condition  monitoring  can  help  to  characterize  sensitivities, 
limits,  and  fragilities. 


Cl  can  reduce  an  adversary’s  understanding  of  system  sensitivities  and 
limits. 

Cl  can  reduce  an  adversary’s  understanding  of  system  sensitivities  and 
limits. 
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Table  A.7 — Continued 


Deception  for  Cl 

Denial  of  ISR  and  Target 
Acquisition 
Criminal  and  Legal 
Penalties  and  Guarantees 
Law  Enforcement;  Civil 
Proceedings 


Deceptions  can  reduce  an  adversary’s  understanding  of  system 
sensitivities  and  limits. 

ISR  denials  can  reduce  an  adversary’s  understanding  of  system 
sensitivities  and  limits. 

Warrantees  and  bonding  can  provide  remediation  for  failed  systems  and 
motivate  manufacturers  to  eliminate  problems  in  the  first  place. 

Warrantees  and  bonding  can  provide  remediation  for  failed  systems. 


Facilitated  by  Design  Sensitivity,  Fragility,  Limits,  or  Finiteness 


Deception  for  ISR  Known  sensitivities  can  be  used  in  our  deceptions  to  determine 

adversary’s  general  knowledge,  capabilities,  and  specific  knowledge 
about  us. 


Table  A.8 

Mitigation  Techniques  That  Address  Unrecoverability 


Primary 

Fleterogeneity 

Redundancy 

Decentralization 

W&A,  Software/Flardware 
Engineering,  Evaluations, 
Testing 
Flardening 

Fault,  Uncertainty,  Validity, 
and  Quality  Tolerance 
and  Graceful  Degradation 
Rapid  Reconstitution  and 
Recovery 
Self-Awareness, 

Monitoring,  and 
Assessments 

Secondary 

Centralization 

Control  of  Exposure, 

Access,  and  Output 
Static  Resource  Allocation 
Dynamic  Resource 
Allocation 

General  Management 
Threat  Response  Structures 
and  Plans 

Adaptability  and  Learning 
Immunological  Defense 
Systems 
Vaccination 


Different  systems  may  fail  at  different  times,  helping  to  avoid  a  complete 
system  failure. 

Redundant  systems  can  provide  fallback  capability  in  the  event  of  an 
unrecoverable  failure. 

Decentralized  operations  can  provide  alternative  capacity  if  parts  of  the 
system  fail. 

Engineering,  W&A,  evaluations,  and  testing  can  help  to  identify  why  a 
system  is  unrecoverable  and  can  recommend  remedies. 

Flardening  can  make  the  system  less  likely  to  fail  in  the  first  place. 

Tolerant  systems  are  less  likely  to  fail  in  the  first  place. 


Rapid  reconstitution  and  recovery  directly  addresses  unrecoverability. 

Early  detection  of  unrecoverable  failures  can  speed  the  implementation 
of  recovery  procedures,  inform  how  to  avoid  failures  in  the  future,  and 
inform  ways  to  make  the  systems  more  recoverable  in  the  first  place. 


Unrecoverable  systems  will  be  easier  to  protect  from  failure  in  the  first 
place  if  they  are  in  a  central  location  close  to  management. 

Partitions  and  isolations  can  help  to  limit  the  scope  of  damage  from  an 
unrecoverable  component. 

Resource  allocations  can  sometimes  work  around  unrecoverable  failures. 

Resource  allocations  can  sometimes  work  around  unrecoverable  failures. 

Management  can  help  avoid  failure  in  the  first  place. 

Response  plans  can  provide  backups  and  contingencies  in  the  event  of 
unrecoverable  failures. 

Learning  can  help  to  avoid  unrecoverable  conditions  in  the  future. 

Unrecoverability  may  be  preempted  on  other  systems  once  an  attack  is 
recognized  and  understood. 

Attacks  can  highlight  unrecoverabilities  and  might  introduce  mitigation 
ideas. 
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Table  A.8 — Continued 


Intelligence  Operations 

Attack  Detection, 
Recognition,  Damage 
Assessment,  and 
Forensics  (Self  and  Foe) 
General  Cl 


ISR  can  inform  us  of  attacks  and  prompt  us  to  protect  unrecoverable 
assets.  It  can  also  inform  us  of  specific  attacks  and  help  filter  them. 

Better  analysis  of  failures  can  help  to  understand  what  caused  the  failure, 
avoid  failure  conditions  in  the  future,  and  correct  failure  modes  in  the 
first  place. 

Cl  can  reduce  an  adversary’s  understanding  of  what  components  are 
unrecoverable. 


Unpredictable  to  Adversary  Cl  can  reduce  an  adversary’s  understanding  of  what  components  are 

unrecoverable. 


Deception  for  Cl 

Denial  of  ISR  and  Target 
Acquisition 
Criminal  and  Legal 
Penalties  and  Guarantees 
Law  Enforcement;  Civil 
Proceedings 


Deceptions  can  reduce  an  adversary’s  understanding  of  what 
components  are  unrecoverable. 

ISR  denials  can  reduce  an  adversary’s  understanding  of  what  components 
are  unrecoverable. 

Warrantees  and  bonding  can  provide  remediation  for  failed  systems  and 
motivate  manufacturers  to  eliminate  problems  in  the  first  place. 

Warrantees  and  bonding  can  provide  remediation  for  failed  systems. 


Table  A.9 

Mitigation  Techniques  That  Address  Behavioral  Sensitivity  or  Fragility 


Primary 

Heterogeneity 

Redundancy 

Decentralization 


WSA,  Software/Hardware 
Engineering,  Evaluations, 
Testing 

Control  of  Exposure, 
Access,  and  Output 
Hardening 

Fault,  Uncertainty,  Validity, 
and  Quality  Tolerance  and 
Graceful  Degradation 
Static  Resource  Allocation 


Heterogeneous  systems  with  different  sensitivities  and  fragilities  can 
provide  alternative  capabilities. 

Redundant  systems  can  help  to  compensate  for  behavioral  sensitivities 
and  fragilities. 

It  can  be  harder  to  understand  and  exploit  the  fragilities  and  limits  in 
systems  when  they  are  dispersed.  Also,  dispersed  systems  of 
autonomous,  heterogeneous  entities  can  provide  more-robust  behavior. 

Engineering,  W&A,  evaluations,  and  testing  can  identify  and  resolve 
behavioral  sensitivities  and  fragilities. 

Controls  can  help  to  protect  fragile  systems  from  harsh  environments  or 
overloading  attacks. 

Hardening  can  make  the  behavior  less  fragile  and  sensitive. 

Tolerant  systems  are  able  to  handle  fragilities,  sensitivities,  and  limits 
better  when  they  happen. 

Resource  allocations  can  balance  loads  to  prevent  failures  and  partition 
work  to  avoid  sensitivities. 


Dynamic  Resource  Resource  allocations  can  balance  loads  to  prevent  failures  and  partition 

Allocation  work  to  avoid  sensitivities. 


General  Management  Attentive  management  can  avoid  stressing  fragile  components  and 

control  behavioral  sensitivities. 


Self-Awareness, 
Monitoring,  and 
Assessments 


Status  monitoring  can  help  management  prevent  the  system  from 
crossing  entering  sensitive  operating  conditions.  Assessments  can 
continue  to  identify  unknown  fragilities  and  sensitivities. 


Secondary 

Centralization  Behavioral  sensitivities  and  fragilities  are  easier  to  observe  and  manage  if 

they  are  centralized. 
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Table  A.9 — Continued 


Threat  Response  Structures 
and  Plans 

Rapid  Reconstitution  and 
Recovery 

Adaptability  and  Learning 

Immunological  Defense 
Systems 

Vaccination 

Intelligence  Operations 

Attack  Detection, 
Recognition,  Damage 
Assessment,  and 
Forensics  (Self  and  Foe) 

General  Cl 

Unpredictable  to  Adversary 

Deception  for  Cl 

Denial  of  ISR  and  Target 
Acquisition 

Criminal  and  Legal 
Penalties  and  Guarantees 

Law  Enforcement;  Civil 
Proceedings 


Response  plans  can  provide  additional  resources  to  minimize  limits  and 
the  effects  of  design  sensitivities. 

A  rapid  recovery  capability  reduces  (but  usually  does  not  eliminate)  the 
effect  of  component  losses  due  to  fragility  and  crossing  limitations. 

Examination  of  performance  can  help  to  locate  fragilities  and  limits  while 
developing  work-arounds. 

Some  systems  automatically  alert,  fuse,  recognize,  update,  patch,  and 
correct  sensitivities. 

Vaccination  uncovers  fragilities  and  limits  directly.  Some  may  be 
corrected  directly,  while  others  could  be  avoided  in  the  future. 

Information  on  attacks  that  target  sensitivities  and  fragilities  can  be  used 
to  plan  and  implement  countermeasures. 

Behavior  and  condition  monitoring  can  help  to  characterize  sensitivities, 
limits,  and  fragilities. 


Cl  can  reduce  an  adversary’s  understanding  of  system  sensitivities  and 
fragilities. 

Cl  can  reduce  an  adversary’s  understanding  of  system  sensitivities  and 
fragilities. 

Deceptions  can  reduce  an  adversary’s  understanding  of  system 
sensitivities  and  fragilities. 

ISR  details  can  reduce  an  adversary’s  understanding  of  system 
sensitivities  and  fragilities. 

Warrantees  and  bonding  can  provide  remediation  for  failed  systems  and 
motivate  manufacturers  to  eliminate  problems  in  the  first  place. 

Warrantees  and  bonding  can  provide  remediation  for  failed  systems. 


Table  A.  10 

Mitigation  Techniques  That  Address  Malevolence 


Primary 

W&A,  Software/Hardware 
Engineering,  Evaluations, 
Testing 

Control  of  Exposure, 
Access,  and  Output 

Trust  Learning  and 
Enforcement  Systems 
N  on-Repudiation 

General  Management 
Intelligence  Operations 
Self-Awareness, 
Monitoring,  and 
Assessments 
Deception  for  ISR 


Engineering,  W&A,  evaluations,  and  testing  can  identify  and  resolve 
malevolent  tendencies. 

Controls  can  help  to  keep  out  or  wrap  malevolent  components,  isolating 
critical  systems,  and  performing  deeper  checks  for  malevolence  in 
critical  areas. 

Trust  learning  and  enforcement  systems  can  help  to  identify  and  control 
malevolent  behavior  and  entities. 

Non-repudiation  can  add  source  information  to  malevolent  behaviors 
and  provide  deterrence  to  malevolent  entities. 

Management  can  actively  monitor  for  malevolent  actors. 

Intelligence  can  specifically  look  for  malevolent  actors. 

Monitoring  can  identify  malevolent  actors  early  on. 


Deceptions  can  be  valuable  ways  to  draw  out  malevolent  actors. 
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Table  A.  1 0 — Continued 


Attack  Detection, 
Recognition,  Damage 
Assessment,  and 
Forensics  (Self  and  Foe) 
General  Cl 

Unpredictable  to  Adversary 

Deception  for  Cl 

Denial  of  ISR  and  Target 
Acquisition 
Deterrence 

Preventive  and  Retributive 
Information/Military 
Operations 
Criminal  and  Legal 
Penalties  and  Guarantees 
Law  Enforcement;  Civil 
Proceedings 


Monitoring  and  assessments  directly  look  for  malevolent  actors. 


Cl  looks  for  malevolent  insiders  that  are  supplying  intelligence  on  the 
system. 

Cl  looks  for  malevolent  insiders  that  are  supplying  intelligence  on  the 
system. 

Deceptions  can  identify  malevolent  insiders  supplying  intelligence  on  the 
system. 

ISR  detail  can  help  prevent  malevolent  actors  from  knowing  where  to 
strike. 

Deterrence  can  dampen  malevolent  tendencies. 

Active  operations  can  eliminate  or  contain  malevolent  actors. 


Penalties  can  deter  malevolent  actors  or  actively  restrain  them  if  caught. 
Enforcement  can  restrain  malevolent  actors. 


Secondary 

Fleterogeneity  Different  systems  may  have  different  malevolent  tendencies,  weaknesses, 

or  even  lack  malevolence  altogether,  mitigating  the  risks  from  the 
malevolent  system. 

Redundancy  Redundancy  could  reduce  the  effectiveness  of  a  single  system  gone  bad. 

Decentralization  Malevolent  entities  are  less  effective  when  control  and  processing  is 

dispersed,  since  it  requires  more  effort  and  purview  over  a  wider  range 
of  dispersed  systems. 

Threat  Response  Structures  Well-developed  plans  can  reduce  the  access  of  and  damage  done  by 
and  Plans  malevolent  actors. 


Immunological  Defense  Monitoring  and  sharing  will  reduce  the  ability  of  malevolent  entities  to 
Systems  remain  hidden  or  to  jump  to  new  systems  and  remain  undetected. 

Vaccination  Simulated  attacks  can  sensitize  the  system  to  malevolence. 


Table  A.  11 

Mitigation  Techniques  That  Address  Rigidity 


Primary 

W&A,  Software/Hardware 
Engineering,  Evaluations, 
Testing 

Trust  Learning  and 
Enforcement  Systems 
Fault,  Uncertainty,  Validity, 
and  Quality  Tolerance  and 
Graceful  Degradation 
Dynamic  Resource 
Allocation 


Engineering,  W&A,  evaluations,  and  testing  can  identify  rigidities  and 
recommend  remedies. 

Trust  systems  adapt  system  accesses  and  information  use  to  changing 
behaviors  and  new  entities. 

Tolerant  systems  are  more  accepting  and  can  operate  in  broader  ranges 
of  inputs. 

Dynamic  allocations  should  adjust  to  current  conditions. 


General  Management  Active  management  can  react  to  new  problems  and  pursue  solutions. 

Threat  Response  Structures  Plans  can  be  adaptive  to  the  current  situation,  especially  when  they 
and  Plans  provide  general  context,  arrangements,  and  alternatives  in  which  local 

responders  can  work. 
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Table  A.  1 1 — Continued 


Rapid  Reconstitution  and 
Recovery 

Adaptability  and  Learning 

Immunological  Defense 
Systems 
Vaccination 
Secondary 
Heterogeneity 

Decentralization 

Static  Resource  Allocation 

Self-Awareness, 
Monitoring,  and 
Assessments 


Rapid  reconstitution  and  recovery  can  provide  flexibility  through  failure 
responsiveness. 

Dynamic  adaptation  and  learning  can  adjust  system  configurations  to 
match  current  needs. 

These  systems  look  for  new  threats  and  solutions.  When  found,  they 
share  information  and  provide  rapid  updates  and  changes  to  the  system. 

Vaccination  shows  where  the  system  needs  to  be  changed. 


Different  systems  may  be  rigid  in  different  ways.  Their  differences  may 
highlight  rigidities  in  the  original  system. 

Decentralized  systems  tend  to  be  more  innovative,  flexible,  and  adaptive 
to  local  conditions. 

Static  allocations  can  introduce  some  level  of  response  to  current 
conditions. 

Monitoring  and  assessments  can  identify  rigidities. 


Attack  Detection, 
Recognition,  Damage 
Assessment,  and 
Forensics  (Self  and  Foe) 
General  Cl 

Unpredictable  to  Adversary 
Deception  for  Cl 

Denial  of  ISR  and  Target 
Acquisition 


Understanding  attacks  often  lead  to  internal  changes  to  improve  security. 


Cl  can  reduce  an  adversary’s  understanding  of  the  system’s  rigidities. 
Cl  can  reduce  an  adversary’s  understanding  of  the  system’s  rigidities. 
Deceptions  can  reduce  an  adversary’s  understanding  of  the  system’s 
rigidities. 

ISR  denial  can  reduce  an  adversary’s  understanding  of  the  system’s 
rigidities. 


Table  A.  12 

Mitigation  Techniques  That  Address  Malleability 


Primary 

W&A,  Software/Hardware 
Engineering,  Evaluations, 
Testing 

Trust  Learning  and 
Enforcement  Systems 

Hardening 

General  Management 

Threat  Response  Structures 
and  Plans 

Self-Awareness, 
Monitoring,  and 
Assessments 


Engineering,  W&A,  evaluations,  and  testing  can  identify  where  the 
system  is  malleable  and  can  recommend  remedies. 

Trust  systems  introduce  more  rigor  and  oversight  to  make  it  harder  to 
control  and  manipulate  the  information  system. 

Hardening  can  make  the  system  less  changeable  and  less  modifiable. 

Management  oversight  can  monitor  for  undesirable  changes  and 
manipulations. 

Plans  provide  structure  to  the  operation  and  contingency,  reducing  the 
likelihood  that  the  system  can  be  manipulated. 

Systems  are  harder  to  manipulate  if  they  are  self-aware  and  can  see  if  you 
are  trying  to  manipulate  them. 


Deterrence 


Deterrence  can  sensitize  actors  and  make  them  less  controllable. 


Secondary 

Heterogeneity  Different  systems  may  have  different  maleabilities. 

Centralization  Centralized  systems  can  be  more  effectively  controlled  and  thus  less 

prone  to  manipulation. 
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Table  A.  1 2 — Continued 


Decentralization 


It  is  harder  to  change  an  entire  distributed  system  than  a  centralized, 
monolithic  one. 


Control  of  Exposure, 
Access,  and  Output 
N  on-Repudiation 

Static  Resource  Allocation 

Adaptability  and  Learning 

Attack  Detection, 
Recognition,  Damage 
Assessment,  and 
Forensics  (Self  and  Foe) 
General  Cl 

Unpredictable  to  Adversary 

Deception  for  Cl 

Denial  of  ISR  and  Target 
Acquisition 
Criminal  and  Legal 
Penalties  and  Guarantees 


Controls  make  it  less  likely  that  a  system  can  be  changed  without  proper 
authorization. 

Systems  can  be  less  likely  to  be  manipulated  if  source  information  is 
always  provided. 

Preplanned  allocations  can  prevent  manipulation  of  allocation 
configurations. 

The  system  will  be  less  likely  to  be  manipulated  if  it  actively  examines 
performance  and  adjusts  to  new  situations. 

Understanding  and  knowledge  of  attacks  can  make  entities  less 
controllable  and  can  identify  unprotected  control  points  for  future 
remediation. 

Cl  can  reduce  an  adversary’s  understanding  of  the  system’s  control 
points  and  manipulabilities. 

Cl  can  reduce  an  adversary’s  understanding  of  the  system’s  control 
points  and  manipulabilities. 

Deceptions  can  reduce  an  adversary’s  understanding  of  the  system’s 
control  points  and  manipulabilities. 

ISR  denial  can  reduce  an  adversary’s  understanding  of  the  system’s 
control  points  and  manipulabilities. 

The  existence  of  penalties  can  make  deterrence  more  effective. 


Table  A.  13 

Mitigation  Techniques  that  Address  Gullibility,  Deceivability,  or  Naivete 


Primary 

WSA,  Software/FIardware 
Engineering,  Evaluations, 
Testing 

Trust  Learning  and 
Enforcement  Systems 
Flardening 


Engineering,  W&A,  evaluations,  and  testing  can  examine  system 
gullibility  and  recommend  compensations. 

Trust  systems  introduce  more  rigor  and  oversight  to  make  it  harder  to 
fool  the  information  system. 

Hardening  can  make  the  system  more  knowledgeable  and  insistent  on 
reliable  information  sources. 


General  Management 

Threat  Response  Structures 
and  Plans 

Adaptability  and  Learning 


Management  oversight  can  monitor  for  undesirable  changes,  share  threat 
knowledge,  and  provide  advice. 

Plans  provide  structure  to  the  operation  and  contingency,  reducing  the 
likelihood  that  the  system  can  be  blindly  manipulated. 

Attention  and  adaptation  to  the  current  situation  can  reduce  blind 
behavior. 


Vaccination 
Intelligence  Operations 

Self-Awareness, 
Monitoring,  and 
Assessments 


Simulated  attacks  can  sensitize  the  system  and  make  it  less  gullible. 
Intelligence  can  provide  information  about  our  adversaries  and  their 
techniques. 

Systems  are  harder  to  manipulate  if  they  are  self-aware  and  can  see  if  you 
are  trying  to  manipulate  them. 


Secondary 

Control  of  Exposure,  Controls  are  often  implemented  with  significant  forethought  and  can 

Access,  and  Output  avoid  some  naive  conditions. 

Non-Repudiation  It  can  be  harder  to  deceive  a  system  if  source  information  is  provided. 
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Table  A.  1 3 — Continued 


Static  Resource  Allocation 
Immunological  Defense 
Systems 

Attack  Detection, 
Recognition,  Damage 
Assessment,  and 
Forensics  (Self  and  Foe) 
General  Cl 

Unpredictable  to  Adversary 

Deception  for  Cl 

Denial  of  ISR  and  Target 
Acquisition 


Static  allocations  often  are  well  engineered  in  advance. 

The  adaptive,  sharing,  and  automatic  maintenance  nature  of  these 
systems  makes  it  harder  to  attack  parts  of  the  system  based  on 
noncompliance  or  ignorance  of  the  latest  information. 

Understanding  and  knowledge  of  attacks  can  make  entities  less  gullible 
and  less  naive  to  the  same  ruses. 


Cl  can  reduce  an  adversary’s  understanding  of  system  biases  and 
operations,  making  it  more  difficult  to  manipulate  it. 

Cl  can  reduce  an  adversary’s  understanding  of  system  biases  and 
operations,  making  it  more  difficult  to  manipulate  it. 

Deceptions  can  reduce  an  adversary’s  understanding  of  system  biases 
and  operations,  making  it  more  difficult  to  manipulate  it. 

ISR  denial  can  reduce  an  adversary’s  understanding  of  system  biases  and 
operations,  making  it  more  difficult  to  manipulate  it. 


Table  A.  14 

Mitigation  Techniques  That  Address  Complacency 


Primary 

W&A,  Software/Fiardware 
Engineering,  Evaluations, 
Testing 

Trust  Learning  and 
Enforcement  Systems 
Dynamic  Resource 
Allocation 

General  Management 
Threat  Response  Structures 
and  Plans 

Adaptability  and  Learning 

Immunological  Defense 
Systems 

Intelligence  Operations 

Self-Awareness, 
Monitoring,  and 
Assessments 
Deterrence 
Secondary 
Centralization 

Control  of  Exposure, 
Access,  and  Output 
Vaccination 
Attack  Detection, 
Recognition,  Damage 
Assessment,  and 
Forensics  (Self  and  Foe) 


Engineering,  W&A,  evaluations,  and  testing  can  help  to  keep  systems 
from  being  complacent  by  identifying  weaknesses  and  ensuring  proper 
procedures. 

Trust  systems  adapt  system  accesses  and  information  use  to  changing 
behaviors  and  new  entities. 

Dynamic  attention  to  resource  allocation  draws  attention  to  current 
conditions. 

Active  management  can  continue  to  look  for  and  adapt  to  new  threats. 

Planning  engages  people  in  active  consideration  of  vulnerabilities  and 
sets  up  contingency  systems  to  facilitate  response. 

Attention  and  adaptation  to  the  current  situation  and  system 
performance  directly  reduce  complacency. 

These  systems  are  always  on  the  alert  for  suspicious  activity  and 
problems. 

Current  and  detailed  understanding  of  adversary  activities  can  motivate 
us  out  of  complacency. 

Direct  knowledge  of  internal  activities  and  attacks  can  motivate  people  to 
action. 

Warnings  and  penalties  can  deter  actors  from  becoming  complacent. 


Centralization  can  introduce  regularly  scheduled  security  reviews  and 
procedures,  thus  reducing  complacency. 

Additional  attention  to  controls  can  reduce  complacency  if  they  are 
actively  maintained  and  improved. 

Simulated  attacks  can  sensitize  the  system  and  keep  it  alert. 

Knowledge  of  the  real  dangers  based  on  prior  attacks  will  make  entities 
less  complacent.  Automated  analysis  systems  can  be  tied  to  protective 
systems  and  directly  reduce  complacency. 
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Table  A.  14 — Continued 


General  Cl 

Unpredictable  to  Adversary 

Deception  for  Cl 

Criminal  and  Legal 
Penalties  and  Guarantees 


Knowledge  about  intelligence  risks  can  motivate  people  to  pay  better 
attention  to  security. 

Knowledge  about  intelligence  risks  can  motivate  people  to  pay  better 
attention  to  security. 

Knowledge  about  intelligence  risks  can  motivate  people  to  pay  better 
attention  to  security. 

Penalties  can  make  warnings  and  deterrence  more  intimidating. 


Table  A.  15 

Mitigation  Techniques  That  Address  Corruptibility  or  Controllability 


Primary 

W&A,  Software/Hardware 
Engineering,  Evaluations, 
Testing 

Control  of  Exposure, 
Access,  and  Output 
Trust  Learning  and 
Enforcement  Systems 
Hardening 

General  Management 

Immunological  Defense 
Systems 

Intelligence  Operations 


Self-Awareness, 
Monitoring,  and 
Assessments 
Deterrence 
Secondary 
Heterogeneity 


Centralization 

Decentralization 

N  on-Repudiation 

Vaccination 

Attack  Detection, 
Recognition,  Damage 
Assessment,  and 
Forensics  (Self  and  Foe) 
General  Cl 


Engineering,  W&A,  evaluations,  and  testing  can  identify  and  remedy 
weaknesses  that  can  be  exploited. 

Control  filters  can  protect  against  common  control  problems  and 
vulnerabilities. 

Trust  systems  introduce  more  rigor  and  oversight  to  make  it  harder  to 
control  and  manipulate  the  information  system. 

Hardening  can  make  the  system  more  knowledgeable  and  insistent  on 
reliable  information  sources. 

Management  oversight  can  monitor  for  undesirable  changes  and 
manipulations. 

Use  of  the  latest  and  best  security  knowledge  and  procedures  will  make  it 
harder  to  directly  attack  the  system. 

Intelligence  can  monitor  for  corruption  directly  and  identify  adversary 
capabilities  and  activities  that  indicate  control  and  access  to  your 
system. 

Self-monitoring  can  identify  corruption.  Assessments  can  identify 
controllability  points  and  corruptibility  danger  signs  (e.g.,  personal 
problems,  careless  behavior). 

Deterrence  can  reduce  corruptibility  and  controllability  of  actors. 


Different  systems  may  have  different  corruptible  or  controllable 
weaknesses  or  have  such  weaknesses  in  different  areas  so  they  can  help 
compensate  for  the  other’s  weaknesses. 

Centralized  control  can  help  to  monitor  and  deal  with  corruption  and 
usurped  control. 

It  is  harder  to  corrupt  or  control  an  entire  distributed  system  than  a 
centralized,  monolithic  one. 

Some  repudiation  systems  protect  information  content  from  corruption 
or  confirm  the  source  of  system  updates. 

Simulated  attacks  can  sensitize  the  system  and  keep  it  alert  to 
corruptions. 

Understanding  and  knowledge  of  attacks  can  make  entities  less 
controllable  and  can  identify  unprotected  control  points  for  future 
remediation. 

Assessments  can  identify  controllability  points  and  corruptibility  danger 
signs  (e.g.,  personal  problems,  careless  behavior). 
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Unpredictable  to  Adversary 

Deception  for  Cl 

Criminal  and  Legal 
Penalties  and  Guarantees 


Assessments  can  identify  controllability  points  and  corruptibility  danger 
signs  (e.g.,  personal  problems,  careless  behavior). 

Deceptions  can  reduce  an  adversary’s  understanding  of  the  system’s 
control  points  and  corruptibility. 

Penalties  can  make  warnings  and  deterrence  more  intimidating. 


Table  A.  16 

Mitigation  Techniques  That  Address  Accessible,  Detectable,  Identifiable, 
Transparent,  or  Interceptable 


Primary 

Decentralization 

W&A,  Software/Hardware 
Engineering,  Evaluations, 
Testing 

Control  of  Exposure, 

Access,  and  Output 
Trust  Learning  and 
Enforcement  Systems 
Hardening 

Fault,  Uncertainty,  Validity, 
and  Quality  Tolerance  and 
Graceful  Degradation 
Threat  Response  Structures 
and  Plans 
General  Cl 

Unpredictable  to  Adversary 

Deception  for  Cl 

Denial  of  ISR  and  Target 
Acquisition 
Deterrence 

Preventive  and  Retributive 
Information/Military 
Operations 

Secondary 

Heterogeneity 

Redundancy 
General  Management 

Immunological  Defense 
Systems 
Vaccination 


Decentralized  systems  are  harder  to  detect,  identify,  track,  access,  and 
intercept  in  their  entirety. 

Engineering,  W&A,  evaluations,  and  testing  can  examine  and  remedy 
weaknesses  that  can  be  exploited. 

These  controls  are  directly  designed  to  reduce  accessibilities, 
detectabilities,  and  interceptions. 

Trust  systems  can  adapt  system  restrict  accesses  and  exposures  to  reliable 
entities. 

Hardening  can  make  the  system  less  accessible,  less  interceptable,  and 
less  likely  to  be  damaged  if  access  is  compromised. 

Tolerant  systems  can  be  less  likely  to  be  compromised  or  damaged  if 
access  is  compromised. 

Response  plans  can  reduce  visibility  and  exposure  based  on  (perceived) 
threats  and  conditions. 

Cl  works  directly  to  minimize  adversarial  capability  to  detect,  identify, 
access,  and  intercept  system  components. 

Cl  works  directly  to  minimize  adversarial  capability  to  detect,  identify, 
access,  and  intercept  system  components. 

Deceptions  can  directly  mask  detections,  identifications,  and 
transparencies. 

Denials  can  directly  mask  detections,  identifications,  and  transparencies. 

Deterrence  can  increase  the  cost  of  monitoring  and  interception  while 
making  them  more  evident. 

Active  retributions  can  protect  access  points,  increase  the  cost  of 
monitoring  and  interception,  and  make  compromises  more  evident. 


A  range  of  different  system  types  would  be  harder  to  track,  identify,  and 
access. 

Multiple  systems  can  be  harder  to  identify  and  track. 

Active  and  well-planned  management  can  help  to  minimize  exposures 
and  interceptions. 

Vigilance  and  automatic  sharing  can  keep  exposure  controls  at  their  peak. 

Attacks  on  exposure  controls  can  strengthen  our  understanding  of  their 
weaknesses,  identify  misconfigurations,  and  motivate  action. 
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T able  A.  1 6 — Continued 


Intelligence  Operations 

Self-Awareness, 
Monitoring,  and 
Assessments 
Attack  Detection, 
Recognition,  Damage 
Assessment,  and 
Forensics  (Self  and  Foe) 
Criminal  and  Legal 
Penalties  and  Guarantees 
Law  Enforcement;  Civil 
Proceedings 


Intelligence  about  adversary’s  sensor  capabilities  can  inform  our 
countermeasure  designs  and  operating  procedures. 

The  more  we  understand  our  own  systems  and  their  exposure,  the  better 
we  can  design  countermeasures  to  protect  them. 

Detection  and  forensics  can  identify  weak  points  while  possibly  informing 
attack  interception  mechanisms  in  a  current  attack. 


Penalties  can  make  warnings  and  deterrence  more  intimidating. 
Enforcement  can  provide  physical  protection  at  access  points. 


Table  A.  17 

Mitigation  Techniques  That  Address  Hard  to  Manage  or  Control 


Primary 

Centralization 

W&A,  Software/Hardware 
Engineering,  Evaluations, 
Testing 

Control  of  Exposure, 
Access,  and  Output 

Trust  Learning  and 
Enforcement  Systems 

Static  Resource  Allocation 

Dynamic  Resource 
Allocation 

General  Management 

Threat  Response  Structures 
and  Plans 

Self-Awareness, 
Monitoring,  and 
Assessments 

Secondary 

Immunological  Defense 
Systems 

Attack  Detection, 
Recognition,  Damage 
Assessment,  and 
Forensics  (Self  and  Foe) 

Deterrence 

Criminal  and  Legal 
Penalties  and  Guarantees 

Law  Enforcement;  Civil 
Proceedings 


Centralization  can  make  it  easier  to  manage  and  control  operations. 

Engineering,  W&A,  evaluations,  and  testing  can  examine  why  the  system 
is  hard  to  manage  and  control  while  making  recommendations  on  how 
to  improve  these  functions. 

Exposure,  access,  and  output  control  structures  can  help  in  the 
management  and  control  of  the  information  flow  into,  out  of,  and 
within  the  information  system. 

Trust  systems  can  introduce  more  rigor  and  support  to  management  of 
the  system,  especially  in  environments  containing  entities  of  unknown 
reliability. 

Resource  allocation  schemes  introduce  additional  management  control 
structures. 

Resource  allocation  schemes  introduce  additional  management  control 
structures. 

Additional  attention  to  management  structures  and  control  points  can 
help  to  bring  systems  under  control. 

Plans  and  contingencies  provide  additional  ways  to  manage  and  control 
the  system. 

Self-information  is  a  key  prerequisite  to  effective  management  and 
control. 


The  automatic  nature  of  the  system  facilitates  management,  especially  of 
distributed  and  diverse  systems. 

Improved  understanding  of  operations  and  weaknesses  can  improve 
manageability. 


Deterrence  is  a  management  tool  to  help  control  actors’  behavior. 
Penalties  can  strengthen  management’s  actions  and  warnings. 

Enforcement  shows  that  disregard  for  management’s  actions  will  result  in 
real  penalties. 


Appendix:  Vulnerability  to  Mitigation  Map  Values  103 


Table  A.  18 

Mitigation  Techniques  That  Address  Self-Unawareness  or  Unpredictability 


Primary 

Centralization 
W&A,  Software/Hardware 
Engineering,  Evaluations, 
Testing 

Trust  Learning  and 
Enforcement  Systems 
Immunological  Defense 
Systems 
Vaccination 

Self-Awareness, 

Monitoring,  and 
Assessments 
Attack  Detection, 
Recognition,  Damage 
Assessment,  and 
Forensics  (Self  and  Foe) 
Secondary 

Static  Resource  Allocation 

Dynamic  Resource 
Allocation 

General  Management 

Threat  Response  Structures 
and  Plans 
General  Cl 

Unpredictable  to  Adversary 
Deception  for  Cl 


Centralization  can  make  it  easier  to  monitor  and  understand  operations. 

Engineering,  W&A,  evaluations,  and  testing  can  identify  and  resolve 
limits  in  self-awareness  and  unpredictability. 

Trust  systems  add  monitors  to  be  more  aware  of  what  is  happening  in  the 
system  and  attributing  actions  to  entities. 

The  self-monitoring  component  of  these  systems  helps  to  provide  insight 
into  systemwide  status  and  behavior. 

Simulated  attacks  will  provide  additional  information  and  insights  into 
the  information  system  and  its  operation  under  stress. 

New  techniques  to  gather  information  about  our  own  system  can  directly 
address  these  deficiencies. 

Monitoring  and  analysis  will  improve  knowledge  and  awareness  of  the 
information  system. 


Resource  allocations  provide  state  information  about  the  information 
system  and  its  processing. 

Resource  allocations  provide  state  information  about  the  information 
system  and  its  processing. 

Self-knowledge  is  an  important  step  in  setting  up  management  structures 
and  controls. 

Plans  often  introduce  new  sources  of  information  about  one’s  own 
system  and  control  structures  to  reduce  unpredictability. 

Cl  often  requires  a  sound  understanding  of  our  system  as  an  intelligence 
target. 

Cl  often  requires  a  sound  understanding  of  our  system  as  an  intelligence 
target. 

Deceptions  often  require  a  sound  understanding  of  our  system  as  an 
intelligence  target. 


Table  A.  19 

Mitigation  Techniques  That  Address  or  Are  Facilitated  by  Predictability 


Primary 

Eleterogeneity 


W&A,  Software/Hardware 
Engineering,  Evaluations, 
Testing 

Dynamic  Resource 
Allocation 


A  range  of  different  system  types  will  require  more  resources  to 
understand  and  predict  how  they  will  operate,  especially  if  their 
interactions  yield  emergent  behaviors. 

Engineering,  W&A,  evaluations,  and  testing  can  identify  and  resolve 
excessive  predictabilities  in  the  system. 

Dynamic  allocations  can  be  less  predictable,  since  they  rely  on  current 
conditions. 


Adaptability  and  Learning 
Immunological  Defense 
Systems 


Adaptation  provides  a  moving  target  for  the  adversary  to  understand. 
The  ability  to  rapidly  insert  modifications  across  the  system  can  make  it 
harder  for  an  adversary  to  maintain  a  common  operating  picture  of  the 
information  system  and  its  configuration. 
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T able  A.  1 9 — Continued 


General  Cl  A  major  goal  of  counterintelligence  is  to  reduce  our  adversary’s  ability  to 

predict  how  our  system  works. 

Unpredictable  to  Adversary  A  major  goal  of  counterintelligence  is  to  reduce  our  adversary’s  ability  to 

predict  how  our  system  works. 

Deception  for  Cl  Deceptions  can  make  the  information  system  harder  to  understand  and 

predict. 

Denial  of  ISR  and  Target  Denial  of  enemy  ISR  interferes  with  the  enemy’s  ability  to  predict  the 

Acquisition  information  system’s  structure  and  function. 

Secondary 

Decentralization 

Control  of  Exposure, 

Access,  and  Output 

General  Management 

Threat  Response  Structures 
and  Plans 

Vaccination 

Attack  Detection, 

Recognition,  Damage 
Assessment,  and 
Forensics  (Self  and  Foe) 

Facilitated  by  Predictability 

Deception  for  ISR  Predictabilities  can  be  leveraged  to  dupe  the  attacker  or  prober  to  see 

how  they  behave  and  how  much  they  know. 


Decentralized  systems  often  contain  a  degree  of  autonomy  and 
heterogeneity,  making  them  less  predictable. 

Controls  can  make  it  harder  for  adversaries  to  predict  how  the  system  is 
configured  inside  the  protected  areas. 

Active  and  well-planned  management  can  help  to  minimize 
dissemination  of  information  about  the  information  system. 

Plans  can  introduce  adaptive  alternatives  and  resources  that  make  the 
system  less  predictable. 

Repeated  red  teaming  can  keep  the  system  in  continual  maintenance  and 
make  it  less  predictable. 

Detection  and  forensics  can  identify  predictable  weak  points  that  require 
corrective  attention. 
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VULNERABILITIES  THAT  CAN  BE  INCURRED  BY  SECURITY  TECHNIQUES 

No  vulnerability  cautions  have  been  identified  for  the  following  security  techniques: 

•  Denial  of  ISR  and  Target  Acquisition 

•  Preventive  and  Retributive  Information /Military  Operations 


Table  A.20 

Vulnerabilities  That  Can  Be  Incurred  from  Heterogeneity 


Primary  Cautions 

Hard  to  Manage  or  Control 

Self-Unawareness  and 
Unpredictability 

A  variety  of  different  system  types  can  be  difficult  to  manage,  maintain, 
and  interoperate. 

A  variety  of  different  system  types  can  be  difficult  to  monitor  and  predict 
how  they  are  interacting  and  operating. 

Secondary  Cautions 

Design  Sensitivity/ 
Fragility/Limits/ 

Finiteness 

Behavioral  Sensitivity/ 
Fragility 

A  collection  of  heterogeneous  systems  may  introduce  design  fragilities  or 
lowest-common-denominator  limits. 

A  collection  of  heterogeneous  systems  may  introduce  behavioral 
sensitivities  or  fragilities  due  to  their  operating  differences  or 
management  challenges. 

Table  A.21 

Vulnerabilities  That  Can  Be  Incurred  from  Redundancy 

Secondary  Cautions 
Separability 

Behavioral 

Sensitivity  /  F  ragility 

Hard  to  Manage  or  Control 

Redundant  systems  (especially  if  located  in  different  places)  might  be 
isolated  and  attacked  separately. 

Redundant,  heterogeneous  systems  could  introduce  voting  paradoxes 
where  the  “best”  decision  may  not  be  reached  (e.g.,  decisions  by 
committee  are  often  weak  compromises). 

Redundant  systems  could  be  harder  to  manage  if  proper  procedures  are 
not  in  place  to  control  their  interactions  and  to  force  proper  decisions. 

Table  A.22 

Vulnerabilities  That  Can  Be  Incurred  from  Centralization 

Primary  Cautions 

Centrality 

Rigidity 

Accessible/Detectable/ 

Identifiable/Transparent/ 

Interceptable 

Centralization  introduces  centrality  directly  by  definition  and  must  be 
judiciously  implemented. 

Centralized  systems  can  become  more  stated  and  rigid,  since  they  tend  to 
reduce  creative  exploration  and  the  use  of  alternative  approaches. 

Centralization  can  make  it  easier  for  adversaries  to  locate,  detect,  and 
identify  operations. 
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Table  A.22 — Continued 


Secondary  Cautions 

Singularity 

Flomogeneity 

Complacency 

Corruptibility/ 

Controllability 

Predictability 


Centralization  could  introduce  singularities  in  the  name  of  cost  savings. 

Centralization  efforts  may  have  a  tendency  to  homogenize  the  systems  to 
simplify  management  and  save  money. 

Some  centralized  systems  become  complacent,  since  they  are  believed  to 
be  more  robust. 

Centralized  systems  have  control  logic  and  paths  that  may  be  usurped. 

Centralized  operations  tend  to  be  more  stated,  predefined,  predictable, 
and  less  innovative. 


Table  A.23 

Vulnerabilities  That  Can  Be  Incurred  from  Decentralization 


Primary  Cautions 

Separability  Dispersed  items  are  easier  to  isolate  and  attack  separately. 

Flard  to  Manage  or  Control  Dispersed,  decentralized  systems  can  be  harder  to  manage  and  control, 

since  they  require  an  extensive  C4I  coordination  system. 
Self-Unawareness  and  It  is  harder  to  understand  and  track  the  operations  of  a  decentralized 

Unpredictability  system. 


Secondary  Cautions 
Logic/Implementation 
Errors;  Fallibility 
Design  Sensitivity/ 
Fragility/Limits/ 
Finiteness 
Behavioral 
Sensitivity/Fragility 
Malleability 

Gullibility/  Deceivability/ 
Naivete 


The  logic  and  interoperability  components  in  a  decentralized  system  can 
make  the  system  more  complex  and  more  prone  to  errors. 

The  logic  and  interoperability  components  in  a  decentralized  system  can 
make  the  system  more  complex  and  more  prone  to  sensitivities  and 
limits  due  to  synchrony,  coordination,  and  communication  limitations. 

Decentralized  systems  (especially  as  they  become  more  complex)  can 
have  behavioral  anomalies. 

Decentralized,  innovative  nodes  with  less-centralized  and  -structured 
control  might  have  less-rigorous  testing  and  thus  be  more  malleable. 

Decentralized,  innovative  nodes  with  less-centralized  and  -structured 
control  might  have  less-rigorous  management  and  thus  be  more 
gullible. 


Table  A.24 

Vulnerabilities  That  Can  Be  Incurred  from  W&A,  Software/Hardware 
Engineering,  Evaluations,  Testing 


Secondary  Cautions 

Complacency  The  existence  of  engineering,  W&A,  evaluations,  and  testing  can  make  a 

system’s  users  and  managers  feel  that  it  has  already  accounted  for 
critical  vulnerabilities  and  hence  will  become  complacent,  especially  to 
novel  threats. 

Predictability  The  use  of  standard  engineering,  W&A,  evaluations,  and  testing  (and 

their  reports  and  documentations)  can  introduce  predictabilities  in  the 
system  operations. 
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Table  A.25 

Vulnerabilities  That  Can  Be  Incurred  from  Control  of  Exposure,  Access,  and  Output 


Primary  Cautions 

Separability 


Rigidity 


Secondary  Cautions 

Centrality 

Design  Sensitivity/ 
Fragility/Limits/ 
Finiteness 
Unrecoverability 

Behavioral 
Sensitivity  /  F  ragility 
Gullibility/  Deceivability/ 
Naivete 
Complacency 

Corruptibility/ 
Controllability 
Flard  to  Manage  or  Control 

Self-Unawareness  and 
Unpredictability 
Predictability 


These  controls  often  introduce  separations  and  could  be  exploited  to 
separate  parts  of  an  otherwise  functioning  system.  Such  separations  can 
degrade  overall  performance  while  improving  security. 

Controls  can  make  the  system  more  rigid  in  general  and  harder  to  modify 
quickly. 


Controls  are  often  centralized  and  may  introduce  another  point  of 
vulnerability. 

Controls  can  introduce  limits  and  sensitivities,  since  their  filters  are  often 
imperfect  and  can  interfere  with  legitimate  communication. 

Restricted  communications  can  make  it  harder  to  monitor  and  quickly 
access  systems  for  recovery  purposes. 

Controls  can  introduce  limits  and  sensitivities,  since  their  filters  are  often 
imperfect  and  can  interfere  with  legitimate  communication. 

Any  control  relies  on  the  use  of  a  bias  function  to  filter  the  interface;  if 
understood,  this  bias  can  be  exploited  to  deceive  the  control. 

Systems  with  extensive  control  are  often  thought  of  as  secure  and  can 
become  complacent  to  their  imperfections. 

Extra  control  structures  always  introduce  another  point  of  potential 
controllability  and  corruption. 

Sophisticated  control  structures  can  be  difficult  to  manage  and  control, 
requiring  extensive  training,  experience,  and  knowledge. 

Restricted  accesses  and  controls  can  make  it  harder  to  monitor  internal 
system  conditions  and  predict  how  the  system  will  perform. 

Some  control  systems  are  standard  in  the  industry,  with  predictable 
limitations  and  default  configurations. 


Table  A.26 

Vulnerabilities  That  Can  Be  Incurred  from  Trust  Learning  and  Enforcement  Systems 


Secondary  Cautions 

Separability  Some  trust  models  can  be  manipulated  by  introducing  false  information 

that  separates  trustworthy  entities. 

Malleability  Some  trust  models  can  be  manipulated  by  introducing  false  information 

in  order  to  establish  trust. 

Gullibility/Deceivability/  Models  that  gauge  trusted  behavior  might  be  fooled  if  the  bias  function  is 
Naivete  known  to  an  adversary. 

Complacency  The  use  of  a  trust  system  can  cause  complacency  if  its  limitations  are  not 

recognized  and  incorporated  into  vulnerability  assessments. 
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Table  A.27 

Vulnerabilities  That  Can  Be  Incurred  from  Non-Repudiation 


Secondary  Caution 

Complacency 

Rigorous  non-repudiation  can  seem  to  provide  significant  security 
protections,  but  the  information  must  be  acted  upon  for  it  to  be  of 
maximal  value. 

Table  A.28 

Vulnerabilities  That  Can  Be  Incurred  from  Hardening 

Primary  Caution 

Rigidity 

Hardening  could  make  the  system  more  rigid. 

Secondary  Cautions 

Design  Sensitivity/ 
Fragility/  Limits/ 
Finiteness 

Complacency 

Flard  to  Manage  or  Control 

Self-Unawareness  and 
Unpredictability 
Predictability 

Sometimes  hardening  is  at  the  expense  of  capacity. 

Hardened  systems  might  be  thought  of  as  invulnerable. 

Rigid,  hardened  systems  can  be  hard  to  manage  or  control,  especially  to 
changing  conditions. 

Some  hardening  approaches  can  make  it  harder  to  monitor  and 
understand  what  is  going  on  in  the  system  and  how  it  will  react. 

Rigid,  hardened  systems  can  be  more  predictable  to  a  knowledgeable 
adversary. 

Table  A.29 

Vulnerabilities  That  Can  Be  Incurred  from  Fault,  Uncertainty,  Validity,  and 

Quality  Tolerance  and  Graceful  Degradation 

Secondary  Cautions 

Design  Sensitivity/ 
Fragility/Limits/ 
Finiteness 

Complacency 
Self-Unawareness  and 
Unpredictability 

Sometimes  systems  with  graceful  degradation  operate  in  a  degraded 
fashion  under  conditions  where  other  systems  would  operate  flawlessly. 

Tolerant  systems  might  be  thought  of  as  invulnerable. 

Some  tolerant  and  gracefully  degrading  approaches  are  hard  for  humans 
to  understand  how  they  work. 

Table  A.30 

Vulnerabilities  That  Can  Be  Incurred  from  Static  Resource  Allocation 

Primary  Cautions 

Separability 

Rigidity 

Gullibility/  Deceivability/ 
Naivete 

Predictability 

Resource  allocations  can  be  exploited  to  attack  or  overwhelm  partitions 
allocated  to  particular  problems. 

Static  allocations  might  become  inappropriate  for  the  current  situation. 

Adversaries  could  manipulate  the  system  into  less-desirable 
configurations.  Static  allocations  may  be  inappropriate  for  current 
conditions. 

Static  allocation  plans  introduce  predictabilities  if  they  are  known. 
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Table  A.30 — Continued 


Secondary  Cautions 

Centrality 

Malleability 

Complacency 


Static  resource  allocations  may  require  centralized  monitoring  and 
control. 

Dynamic  allocation  triggers  could  be  manipulated  with  activity  to  move 
the  system  into  less-desirable  configurations. 

The  existence  of  allocation  plans  may  make  one  feel  overly  secure. 


Table  A.31 

Vulnerabilities  That  Can  Be  Incurred  from  Dynamic  Resource  Allocation 


Secondary  Cautions 

Centrality  Dynamic  resource  allocations  may  require  centralized  monitoring  and 

control. 


Separability 

Behavioral 
Sensitivity  /  F  ragility 
Malleability 

Gullibility/  Deceivability/ 
Naivete 
Complacency 
Corruptibility/ 
Controllability 
Hard  to  Manage  or  Control 
Self-Unawareness  and 
Unpredictability 

Predictability 


Some  allocation  approaches  may  be  exploited  to  cut  off  parts  of  the 
system. 

Some  dynamic  resource  allocations  can  have  ranges  with  behavioral 
sensitivities. 

Dynamic  allocation  triggers  could  be  manipulated  with  activity  to  move 
the  system  into  less-desirable  configurations. 

Dynamic  allocations  could  be  used  to  manipulate  the  system  into  less- 
desirable  configurations. 

The  existence  of  allocation  plans  may  make  one  feel  overly  secure. 

Dynamic  allocation  control  structures  could  be  exploited. 

Dynamic  allocations  can  be  difficult  to  manage  as  options  increase. 

It  may  be  hard  to  predict  how  the  system  will  operate  under  different 
allocations.  It  may  also  be  difficult  to  monitor  the  system  status  if  the 
allocations  are  made  automatically  and  rapidly. 

Even  dynamic  allocations  can  be  predictable  if  the  decision  criteria  are 
known. 


Table  A.32 

Vulnerabilities  That  Can  Be  Incurred  from  General  Management 


Many  management  organizations  have  strong  centralities. 

Highly  managed  organizations  tend  to  be  homogeneous  and  intolerant  of 
alternative  approaches,  systems,  and  designs  that  introduce  additional 
management  costs  and  efforts. 


Primary  Cautions 

Centrality 

Homogeneity 


110  Finding  and  Fixing  Vulnerabilities  in  Information  Systems:  VAM  Methodology 


Table  A.32 — Continued 


Secondary  Cautions 

Uniqueness 

Design  Sensitivity/ 
Fragility/Limits/ 
Finiteness 
Rigidity 

Gullibility/  Deceivability/ 
Naivete 
Complacency 

Predictability 


Key  management  functions  can  be  placed  with  unique  components  or 
people. 

Management  controls  can  introduce  limits  and  fragilities  on  capabilities. 


Management  systems  can  be  rigid  and  hard  to  adapt  to  new  situations. 

Rigid,  highly  structured  management  systems  can  be  deceived  when  their 
processes  are  well  understood  by  adversaries. 

Detailed  management  procedures  can  lead  people  to  believe  that  the 
systems  are  sufficiently  protected. 

Flighly  structured  and  micromanaged  systems  can  follow  well-known 
approaches.  Documentation  about  these  management  structures  can 
make  it  predictable  if  it  is  compromised. 


Table  A.33 

Vulnerabilities  That  Can  Be  Incurred  from  Threat  Response  Structures  and  Plans 


Primary  Cautions 

Separability 

Rigidity 

Gullibility/  Deceivability/ 
Naivete 


Secondary  Cautions 

Centrality 

Flomogeneity 

Logic/Implementation 
Errors;  Fallibility 
Design 

Sensitivity/Fragility/ 
Limits  /  Finiteness 
Behavioral 
Sensitivity  /  F  ragility 
Complacency 

Accessible/Detectable/ 
Identifiable/Transparent/ 
Interceptable 
Self-Unawareness  and 
Unpredictability 
Predictability 


Some  response  structures  disconnect  and  partition  the  system  in  high- 
threat  conditions  to  protect  from  attack. 

Plans  might  be  overly  structured  and  rigid,  especially  if  they  apply 
broadly  and  do  not  account  for  local  differences. 

Overly  structured  and  rigid  plans  might  be  triggered  to  move  the  system 
into  overly  protective  states,  reducing  capability  at  the  low  cost  of 
tripping  the  triggers. 


Some  response  structures  and  plans  employ  centralized  monitoring, 
decisionmaking,  and  implementation. 

Plans  might  dictate  uniform  responses  across  the  board  rather  than 
allowing  local  differences. 

Many  plans  have  never  been  fully  exercised  in  the  real  world  and  may 
contain  unforeseen  difficulties. 

Some  response  actions  can  limit  performance  as  they  seek  to  protect 
critical  capabilities. 

Many  plans  have  never  been  fully  exercised  in  the  real  world  and  may 
contain  unforeseen  difficulties. 

The  presence  of  contingency  plans  can  lead  to  complacency  unless  they 
are  often  reexamined  and  expanded. 

If  care  is  not  taken,  the  actions  taken  in  the  plan  can  be  quite  visible  and 
convey  state  information. 

Many  plans  have  never  been  fully  exercised  in  the  real  world  and  may 
contain  unforeseen  difficulties. 

If  well  known,  contingency  plans  can  make  it  easier  to  predict  how  the 
system  will  react  to  threats  and  damage. 
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Table  A.34 

Vulnerabilities  That  Can  Be  Incurred  from  Rapid  Reconstitution  and  Recovery 


Secondary  Caution 

Complacency  The  ability  to  rapidly  recover  and  reconstitute  (e.g.,  reboot)  the  original 

system  state  can  make  us  complacent  about  failures  and  compromises  of 
the  system  and  give  us  a  false  sense  of  operational  capability. 


Table  A.35 

Vulnerabilities  That  Can  Be  Incurred  from  Adaptability  and  Learning 


Secondary  Cautions 
Behavioral 
Sensitivity/Fragility 
Malleability 

Gullibility/  Deceivability/ 
Naivete 

Hard  to  Manage  or  Control 
Self-Unawareness  and 
Unpredictability 


Adaptive  exploration  of  parameters  can  temporarily  introduce  fragilities 
and  degraded  performance  until  they  are  well  examined. 

Adaptation  algorithms,  if  known,  could  be  exploited  to  mislead  the 
system. 

Adaptation  algorithms,  if  known,  could  be  exploited  to  mislead  the 
system. 

If  independent,  adaptive  systems  can  be  harder  to  control. 

Some  adaptive  algorithms  are  hard  for  humans  to  understand  how  they 
work. 


Table  A.36 

Vulnerabilities  That  Can  Be  Incurred  from  Immunological  Defense  Systems 


Secondary  Cautions 

Centrality 


Homogeneity 


Malleability 


Complacency 

Corruptibility/ 

Controllability 

Predictability 


Some  immunological  systems  rely  on  centralized  information  and 
coordination  sites.  Decentralized,  peer-to-peer  architectures  mitigate 
this. 

Since  it  is  easier  to  apply  this  approach  to  homogeneous  components,  its 
application  may  drive  management  to  more  homogeneous 
configurations. 

The  automatic  update  path  provides  a  new  means  for  broad  manipulation 
across  the  information  system  components  and  must  be  highly 
protected. 

While  valuable  and  seemingly  robust,  these  systems  are  not  perfect  and 
must  not  lead  to  complacency  in  other  security  areas. 

The  automatic  update  path  provides  a  new  means  for  broad  corruptions 
across  the  information  system  components  and  must  be  highly 
protected. 

The  sharing  channel  could  introduce  a  means  for  adversary  intelligence. 
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Table  A.37 

Vulnerabilities  That  Can  Be  Incurred  from  Vaccination 


Secondary  Cautions 
Flomogeneity 


Malevolence 


Corruptibility/ 

Controllability 

Predictability 


Because  it  is  easier  to  apply  this  approach  to  homogeneous  components, 
its  application  may  drive  management  to  more  homogeneous 
configurations. 

One  must  be  careful  that  simulated  attacks  do  not  introduce  irreparable 
damage,  introduce  new  problems,  or  make  it  easier  for  adversaries  to 
understand  how  to  attack  the  system. 

One  must  be  careful  that  simulated  attacks  do  not  corrupt  the  system. 

One  must  be  careful  that  simulated  attacks  do  not  make  it  easier  for 
adversaries  to  understand  how  to  attack  the  system. 


Table  A.38 

Vulnerabilities  That  Can  Be  Incurred  from  Intelligence  Operations 


Secondary  Cautions 

Centrality 

Separability 

Complacency 


Intelligence  information  flows  are  usually  centralized  to  coordinate  and 
exploit  the  information. 

Intelligence  activities  can  make  individuals  suspicious  of  each  other. 
The  existence  of  an  intelligence  capability  can  make  us  feel  more  secure 
than  is  warranted. 


Table  A.39 

Vulnerabilities  That  Can  Be  Incurred  from  Self-Awareness,  Monitoring,  and  Assessments 


Secondary  Cautions 

Centrality  Monitoring  the  entire  system  may  require  a  centralized  fusion  and 

exploitation  capability. 

Complacency  Large  amounts  of  indigestible  information  or  long  periods  of  false 

positives  can  make  people  indifferent. 

Accessible/Detectable/  Our  monitors  might  be  exploited  by  our  adversaries. 
Identifiable/Transparent/ 

Interceptable 


Table  A.40 

Vulnerabilities  That  Can  Be  Incurred  from  Deception  for  ISR 


Secondary  Cautions 

Centrality  Effective  deceptions  often  require  coordinated  planning. 

Flard  to  Manage  or  Control  Deceptions  in  our  own  systems  can  confuse  our  own  managers  if  they  are 

not  identified. 

Self-Unawareness  and  Deceptions  in  our  own  systems  can  confuse  our  own  managers  and 

Unpredictability  components  if  they  are  not  identified. 
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Table  A.41 

Vulnerabilities  That  Can  Be  Incurred  from  Attack  Detection,  Recognition, 
Damage  Assessment,  and  Forensics  (Self  and  Foe) 


Secondary  Cautions 

Centrality 

Separability 

These  assessments  may  require  centralized  information  sources  to 
facilitate  fusion  and  other  analyses. 

Uncertain  or  faulty  detections  or  conclusions  can  lead  to  internal 
suspicions,  disconnections,  and  denials  of  information  exchange. 

Table  A.42 

Vulnerabilities  That  Can  Be  Incurred  from  General  Counterintelligence 

Secondary  Cautions 
Separability 

Behavioral 

Sensitivity/Fragility 

Gullibility/Deceivability/ 

Naivete 

Hard  to  Manage  or  Control 

Excessive  fears  and  alarms  can  make  entities  suspect  one  another,  and 
lead  to  isolation. 

Excessive  concerns  about  compromises  and  intrusions  can  make  the 
system  paranoid. 

Even  counterintelligence  efforts  can  be  manipulated. 

Counterintelligence  efforts  can  interfere  with  regular  management 
functions  and  controls. 

Table  A.43 

Vulnerabilities  That  Can  Be  Incurred  from  Unpredictable  to  Adversary 

Primary  Caution 

Self-Unawareness  and 
Unpredictability 

Unpredictability  and  complexities  can  confuse  our  own  managers  and 
components  if  they  are  not  identified. 

Secondary  Cautions 
Separability 

Behavioral 

Sensitivity  /  F  ragility 
Gullibility/  Deceivability/ 
Naivete 

Hard  to  Manage  or  Control 

Excessive  fears  and  alarms  can  make  entities  suspect  one  another  and 
lead  to  isolation. 

Excessive  concerns  about  compromises  and  intrusions  can  make  the 
system  paranoid. 

Even  counterintelligence  efforts  can  be  manipulated. 

Counterintelligence  efforts  can  interfere  with  regular  management 
functions  and  controls. 

Table  A.44 

Vulnerabilities  That  Can  Be  Incurred  from  Deception  for  Cl 

Primary  Caution 

Self-Unawareness  and 
Unpredictability 

Deceptions  can  confuse  our  own  managers  and  components  if  they  are 
not  identified. 
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Table  A. 44 — Continued 

Secondary  Cautions 
Separability 

Behavioral 

Sensitivity  /  F  ragility 

Flard  to  Manage  or  Control 

Excessive  deceptions  can  make  it  hard  for  entities  to  know  what  is  real, 
leading  to  internal  suspicions  and  isolations. 

Excessive  deceptions  can  introduce  behavioral  anomalies  when 
legitimate  users  are  not  aware  of  deceptions. 

Deceptions  can  interfere  with  regular  management  functions  and 
controls. 

Table  A.45 

Vulnerabilities  That  Can  Be  Incurred  from  Deterrence 

Secondary  Cautions 

Rigidity 

Complacency 

Predictability 

Strong  threats  and  penalties  can  make  the  system  conservative,  rigid,  and 
cautious. 

Strong  deterrence  may  naively  make  the  system  feel  secure. 

Strong  threats  and  penalties  can  make  the  system  conservative,  rigid, 
cautious,  and  thus  predictable. 

Table  A.46 

Vulnerabilities  That  Can  Be  Incurred  from  Criminal  and  Legal  Penalties  and  Guarantees 

Secondary  Caution 

Complacency 

Strong  penalties  and  guarantees  can  introduce  a  false  sense  of  security. 

Table  A.47 

Vulnerabilities  That  Can  Be  Incurred  from  Law  Enforcement;  Civil  Proceedings 

Secondary  Caution 

Complacency 

Strong  law  enforcement  can  introduce  a  false  sense  of  security. 
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